I’m not sure whether you’re right: imagine a ADC converting voltage to numbers.
I think it will be symmetrical and if it covers a range from -1 … +1 volts then
in 16 Bits -1 volt will result in -32767 and +1 volt in 32767. And also vice
versa: I’d assume a DAC generates identical voltages with different signs for
identical integers with different signs. That means that just because integers
are not symmetrical in their negative and positive range this doesn’t imply a
ADC will handle positive and negative voltages differently and thus behave
asymmetrical and create different integer values for the same voltage with
different signs. So apart from your int->float->int conversion being much more
CPU intensive because you have to be aware of the leading sign it also could to
introduce a little DC offset if you’re doing processing etc. in the float area
as you’re scaling positive and negative samples differently. In my eyes it’s
correct to use the same factor for negative and positive values – and it will
even be less CPU intensive and bit transparent.
Von: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> Im
Auftrag von Tim Roberts
Gesendet: Mittwoch, 22. August 2018 20:15
An: wdmaudiodev@xxxxxxxxxxxxx
Betreff: [wdmaudiodev] Re: AW: Re: bit transparency from app to WDM audio
driver depending from API?
Johannes Freyberger wrote:
I know, I have to scale to the range of -1.0 to +1.0 for float audio. I do
this by dividing by 32768 for 16 bit audio and by 8388608 for 24 bit audio.
But that's doesn't map the full range. 16-bit values run from -32768 to
+32767. So, with your division, you can get a value of -1.0, but you can never
reach +1.0.
I don't know if the kernel's conversion actually tries to achieve [-1.0,1.0],
or if they are satisfied with [-1.0,1.0).
--
Tim Roberts, timr@xxxxxxxxx <mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.