Support and General Use > Audio Playback, Database and Playlists

Bit depth, Dithering, and the Rockbox audio path

(1/3) > >>

dconrad:
This is entirely out of pure curiosity, but I recently learned what dithering is, and noticed Rockbox has this capability. That got me thinking, I know parts of the RB audio path/pipeline are fixed to 16-bit. What does the audio path's bit depth look like, anyway? Maybe there's already a thread that explains this, but I did a quick search and didn't get much, especially within the last decade.

Say I've got a 32-bit FLAC file. I understand most of the sound processing stuff is 32-bit, so does it stay 32-bit all the way through the DSP stuff and then get truncated/dithered once to 16-bit, or does it get converted to 16-bit, upped to 32-bit (if stuff is enabled), and then converted again to 16-bit?

If the latter, is dithering applied both times the audio is converted down?

Another quite a bit more specific question... is dithering twice a bad thing, if the audio must be converted to lower bit depth twice? I'm working on getting higher bit depth volume working on the Eros Q, and it will go 16 --> 32 --> 24 (that's the plan, anyway...), could/should it be dithered there as well? Once I get the basic functionality working, anyway.

Edit: Or, really the ideal case would probably be to do volume scaling direct to 24 and avoid that whole question anyway, but I'd have to understand the math well enough to make that happen  ;D One step at a time...

7o9:
I am not a mathematician so I googled.

Reading this explained to me what you are trying to decide: https://www.waves.com/audio-dithering-what-you-need-to-know

Quantization from higher bit depth to lower does not require dithering as a rule. Doing it multiple times adds noice each time. If you go up from 16/24 to 32 you are not losing any information. Changing the volume at 32 and then going back to the original should still bot lose information. Going from a 24 original to 16 does, as you have to perform quantization: https://en.wikipedia.org/wiki/Quantization_(signal_processing).

In your example, why go down to 24 bit again?

dconrad:

--- Quote ---In your example, why go down to 24 bit again?
--- End quote ---

For reasons only Ingenic know, they limited the audio module in the X1000 processor to 24-bit samples, so that's the highest bit depth we can send to the DAC. Not bad by any means, but just like... why not 32?

saratoga:

--- Quote from: dconrad on July 23, 2021, 11:57:25 AM ---This is entirely out of pure curiosity, but I recently learned what dithering is, and noticed Rockbox has this capability. That got me thinking, I know parts of the RB audio path/pipeline are fixed to 16-bit. What does the audio path's bit depth look like, anyway? Maybe there's already a thread that explains this, but I did a quick search and didn't get much, especially within the last decade.

Say I've got a 32-bit FLAC file. I understand most of the sound processing stuff is 32-bit, so does it stay 32-bit all the way through the DSP stuff and then get truncated/dithered once to 16-bit, or does it get converted to 16-bit, upped to 32-bit (if stuff is enabled), and then converted again to 16-bit?
--- End quote ---

I don't think 32 bit flac exists, but ignoring that, since these are 32 bit processors without floating point everything is done natively on 32 bit.  At the end of processing it is converted to 16 bit in order to double the PCB buffer capacity and because most hardware expects 16 bit samples.  For the most part smaller than 32 bit samples are not used because they're slower on most of our hardware.


--- Quote from: dconrad on July 23, 2021, 11:57:25 AM ---Another quite a bit more specific question... is dithering twice a bad thing, if the audio must be converted to lower bit depth twice? I'm working on getting higher bit depth volume working on the Eros Q, and it will go 16 --> 32 --> 24 (that's the plan, anyway...), could/should it be dithered there as well? Once I get the basic functionality working, anyway.
--- End quote ---

You only dither when reducing bit depth, never increasing.  In this case though its not needed since nothing can actually decode a 24 bit sample, so the dither would be lost anyway.


--- Quote from: dconrad on July 23, 2021, 11:57:25 AM ---For reasons only Ingenic know, they limited the audio module in the X1000 processor to 24-bit samples, so that's the highest bit depth we can send to the DAC. Not bad by any means, but just like... why not 32?
--- End quote ---

Most real world hardware has somewhere between 14 to 18 bits, so values larger than 24 bit do not make sense.  They simply waste memory. 

dconrad:

--- Quote from: saratoga on July 23, 2021, 05:02:25 PM ---I don't think 32 bit flac exists, but ignoring that, since these are 32 bit processors without floating point everything is done natively on 32 bit.  At the end of processing it is converted to 16 bit in order to double the PCB buffer capacity and because most hardware expects 16 bit samples.  For the most part smaller than 32 bit samples are not used because they're slower on most of our hardware.

--- End quote ---

So that confirms my question that the current audio path only goes down to 16-bit once?


--- Quote ---You only dither when reducing bit depth, never increasing.  In this case though its not needed since nothing can actually decode a 24 bit sample, so the dither would be lost anyway.

--- End quote ---

Right. So, in my question, I am reducing bit depth a second time (from 32 to 24), so is it (theoretically) advisable to dither a second time?


--- Quote ---Most real world hardware has somewhere between 14 to 18 bits, so values larger than 24 bit do not make sense.  They simply waste memory.

--- End quote ---

That's the weird thing. For 24 bit mode, the X1000 AIC wants data in a 32-bit container, and if I recall correctly, even the I2S output is padded with zeroes out to 32 bits. So it's not like they're saving memory, as far as I can tell. And yeah, the PCM5102a dac accepts 32-bit data, though what it does internally I don't know.

Navigation

[0] Message Index

[#] Next page

Go to full version