What bit depth should I set my DAC to?

[Julf]

We already discussed why. 64-bit software DSP, software digital XO's, softare IIR/FIR filters, individual multi-channel leveling, individual channel time alignments, Accurate, Audiolense, DRC-FIR, etc., using a PC versus a locked-in-time limited-DSP-chip tied to a vendor specific piece of hardware, ... Doing it in the PC is much more versatile, extendable, and does NOT lock you to a single-source vendor's hw/sw solution. A single interface to control everything from configuration to runtime.

All that is a different discussion. I was asking about volume control (that DAC chips do just fine). Even in the cases you mention, 24 bits to the DAC is more than enough (considering the DAC only does 21 bits in the best of cases).

 

[Krunok]

No matter if USB chip (like XU208) or DAC chip (like ESS) do volume control they do it in a same way: no matter if they receive 16 bit, 24 bit or 32 bit they always calculate with 32 bit precision (like shown in that ESS article) and the result stays in 32 bit notation up to the DA conversion process. (it doesn't get rounded nor truncated)

 

[Julf]

No matter if 32 bit USB chip (like XU208) or DAC chip (like ESS) do volume control they do it in a same way: no matter if they receive 16 bit, 24 bit or 32 bit they always calculate with 32 bit precision (like shown in that ESS article) and the result stays in 32 bit notation up to the DA conversion process. (it doesn't get rounded nor truncated)

Sure, but what g29 is advocating is a 32-bit (or more?) path from PC to DAC to avoid rounding/truncation after DSP done in the PC. I am pointing out that it is pointless as the DAC effectively rounds it off at 20 or 21 bits anyway.

 

[Krunok]

Sure, but what g29 is advocating is a 32-bit (or more?) path from PC to DAC to avoid rounding/truncation after DSP done in the PC. I am pointing out that it is pointless as the DAC effectively rounds it off at 20 or 21 bits anyway.

Foobar have batter volume control than ESS/XU208 chips as it uses 32 bit float instead of 32 bit integer precision. As long as material is not clipping there will be no difference however.

Why would DAC round off 32 bit data to 20 or 21 bit?

 

[Julf]

Foobar have batter volume control than ESS/XU208 chips as it uses 32 bit float instead of 32 bit integer precision. As long as material is not clipping there will be no difference however.

32 bit floating point only has 24 bit precision - 32 bit integer is actually much more precise.

Why would DAC round off 32 bit data to 20 or 21 bit?

ENOB (Effective Number of Bits). Anything beyond 21 bits (in the best possible DACs) disappears in noise.

 

[Krunok]

32 bit floating point only has 24 bit precision - 32 bit integer is actually much more precise.

Sorry, I meant 64 bit floating point.

ENOB (Effective Number of Bits). Anything beyond 21 bits (in the best possible DACs) disappears in noise.

At the end that is true, however, from the algorithm (calculation) point of view that is not relevant.

 

[Julf]

Sorry, I meant 64 bit floating point.

OK, that makes sense - more so for complex DSP, not really needed for attenuation.

At the end that is true, however, from the algorithm (calculation) point of view that

is not relevant.

It is relevant to the argument by g29.

 

[Krunok]

OK, that makes sense - more so for complex DSP, not really needed for attenuation.

WHen I tested foobar's volume control vs the one done by Volumio (or better to say ALSA) via XU208 chip in my Topping D10 I didn't notice any difference as long as material was not clipping. IMHO 32 bit volume control in XU208 and ESS DACs works perfectly well.

 

[Julf]

WHen I tested foobar's volume control vs the one done by Volumio (or better to say ALSA) via XU208 chip in my Topping D10 I didn't notice any difference as long as material was not clipping. IMHO 32 bit volume control in XU208 and ESS DACs works perfectly well.

Inded.

 

[mykeldg]

wow interesting development. thanks for all your inputs. I know I posted subjective findings -- I think its just fair to doubt it considering this is a science forum and I was expecting a science-based answer.

Again, my subjective hearing observed the ff:
- Do you hear a subtle improvement in depth and midrange detail when switching to WASAPI from non wasapi? That is a similar difference I hear when switching 16/44 to 32/44.

Now for the non-subjective science bit, I admit I would leave that to more qualified people of this forum, which we are not in short of.

Thanks again I guess I will use 32bit since I use the volume control a fair bit even down to 10%.

 

[Krunok]

Again, my subjective hearing observed the ff:
- Do you hear a subtle improvement in depth and midrange detail when switching to WASAPI from non wasapi? That is a similar difference I hear when switching 16/44 to 32/44.

Hard to tell as it is not a blind test, thus unreliable. But stick to exclusive WASAPI, it is technically superior.

 

[bennetng]

Let's use SoX's -stats command to inspect some files.

SoX says the 32-bit float file has a precision of 25-bit (rather than the generally claimed 24-bit), it is because you need to give up half of 24-bit integer values to represent negative values (-8388608 to +8388607), on the other hand floating point values are always signed. A 32-bit floating point value can represent integer values from -16777216 to +16777216 symmetrically and losslessly.

https://en.wikipedia.org/wiki/Singl...int_format#Precision_limits_on_integer_values
https://gist.github.com/skratchdot/c0602fa21a2020f015fc#file-help-format-txt

Also, while the concept presented in the ESS pdf is okay, don't take the numbers they mentioned very seriously.

Firstly, 30003 * 0.3162 (-10dB) is 9486.9486, and it is even less accurate than the 16-bit value (9488). Secondly, why did they use more digits (0.0177828) to represent -35dB? With the higher precision Windows calculator as reference (left column), 16-bit fixed-point is good enough to represent 0.3162, but not good enough for 0.0177828. -10dB is rounded to 20724 and -35dB is rounded to 1165 respectively.

Thirdly the binary number they quoted is not 533.5372.

Fourthly, If you can only use 32 fixed bits for calculation, you need to take into account that when you multiply two integers, unless both of them are 16-bit numbers, otherwise the result can be longer than 32 bits and results in overflow. You can only do 30003 * 20724 for -10dB and 30003 * 1165 for -35dB. Floating point math does not have this issue as it scales the bits automatically.

The ESS pdf only explained how fractional numbers can be represented in fixed-point, but not how the calculation is done.

Anyway, here is a calculator I wrote the demonstrate the math. By default it operates in 64-bit float, but the results can be displayed in 32-bit float (single) and fixed-point by specifying the desired bit-depth. I posted this calculator last year but this one is an updated version with enhanced precision on the "Analog" section. Keep in mind that the displayed values may slightly vary in different browsers and it is normal.

Anyway, the only scenario that I can discern a difference is when something is clipped.

 

[Veri]

Anyway, the only scenario that I can discern a difference is when something is clipped.

Thanks for the math and conclusion