• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

What bit depth should I set my DAC to?

daftcombo

Major Contributor
Forum Donor
Joined
Feb 5, 2019
Messages
3,687
Likes
4,068
thanks all. I do hear some slight & very subtle differences when i switch between all 3
- 16bit is the clearest but is very flat sounding ,tends to sound more open and airy but with less depth. tends to sound lifeless at very low volumes compared to 24 & 32bit. (possibly because it is losing bits when I lower the volume digitally)
- 32bit has more depth but less aliased sounding / less "sharpness" yet retains dynamics ,more punch even when i lower the volume
-24bit is midway between both

anyway, these are just my "noob" observations. i don't know how it really fares technically
Would like to see an ABX of 16bit VS 32bit from you.
Unless you listen to extremely dynamic music & louder than 96dB, it's unlikely you pass it.
 

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
Modern DACS have 32-bit inputs. 16-bit content can be converted to 64-bit, volume control applied with 64-bit precision math and then fed back into the DAC at 32-bit (without dropping back down to 16 bit).

I repeat: I think you miss my point. I wrote "It doesn't matter how many bits the volume control is...", as I was pointing out that even if you do the calculations in 128 bit floating point or whatever, you are still limited by the noise floor of the DAC. 32-bit input is of course totally silly and purely marketing-driven.

How many analog preamps have noise floors lower than that of the current generation of DACS ??? Maybe ASR should be testing analog preamps as well ???

That's exactly my point. 105 dB (a very good value for a preamp) is equivalent to less than 18 bits, so you are perfectly fine doing 24-bit digital volume control.
 

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
Unless you listen to extremely dynamic music & louder than 96dB, it's unlikely you pass it.

I would love to see a recording with more than 96 dB dynamic range.
 

g29

Addicted to Fun and Learning
Joined
May 1, 2019
Messages
520
Likes
318
I repeat: I think you miss my point. I wrote "It doesn't matter how many bits the volume control is...", as I was pointing out that even if you do the calculations in 128 bit floating point or whatever, you are still limited by the noise floor of the DAC. 32-bit input is of course totally silly and purely marketing-driven.



That's exactly my point. 105 dB (a very good value for a preamp) is equivalent to less than 18 bits, so you are perfectly fine doing 24-bit digital volume control.

But you do realize, the $15K preamp is the limiting factor between the volume control and a $100 DAC ?
 

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
But you do realize, the $15K preamp is the limiting factor between the volume control and a $100 DAC ?

Yes. Which is why I don't worry about modern DAC performance - or $15K preamps. :)
 

g29

Addicted to Fun and Learning
Joined
May 1, 2019
Messages
520
Likes
318
... 32-bit input is of course totally silly and purely marketing-driven..

I think you miss the point of the 32-bit input. From my understanding, it facilitates external software volume control with out the bit-loss of doing it in 16-bit and as ESS points out, allows internal volume control without the bit-loss of doing it in 16 bit. Why spend $$$ on an extra preamp (analog volume control) when it comes included in the price of the DAC ???
 
Last edited:

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
I think you miss the point of the 32-bit input. From my understanding, it allows external software volume control with out the bit-loss of doing it in 16-bit and as ESS points out, allows internal volume control without the bit-loss of doing it in 16 bit.

32-bit input is pointless. Software volume control is best done by communicating the volume setting to the DAC. Why send 32 instead of 16 or 24 bits per sample, when all you need is 16 or 24 bits per sample, and 8 bits of scaling information once per volume setting change (that doesn't happen very often)? Most DSP chips use 64 or more bits internally anyway, which is what counts.
 

g29

Addicted to Fun and Learning
Joined
May 1, 2019
Messages
520
Likes
318
32-bit input is pointless. Software volume control is best done by communicating the volume setting to the DAC. Why send 32 instead of 16 or 24 bits per sample, when all you need is 16 or 24 bits per sample, and 8 bits of scaling information once per volume setting change (that doesn't happen very often)? Most DSP chips use 64 or more bits internally anyway, which is what counts.

Because DSP is also done in software in 64-bits (not just DSP chips). Why buy a time-locked DSP chip integrated into custom hardware (e.g. DEQX) when it can be done (or second/third sourced) in a PC (Accourate, Audiolense, etc.) and can easily be upgraded with software updates and CPUs as processor technology progresses ? The 32-bit interface is probably a magnitude of scale purchasing decision (as well as USB aggregate bandwidth considerations).
 

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
Because DSP is also done in software in 64-bits (not just DSP chips). Why buy a time-locked DSP chip integrated into custom hardware (e.g. DEQX) when it can be done (or second/third sourced) in a PC (Accourate, Audiolense, etc.) and can easily be upgraded with software updates and CPUs as processor technology progresses ? The 32-bit interface is probably a magnitude of scale purchasing decision (as well as USB aggregate bandwidth considerations).

Fair enough for complex DSP, but attenuation is a trivial operation that any DAC can do just fine. Again, you need the extra precision only during the operation, not before or after.
 

g29

Addicted to Fun and Learning
Joined
May 1, 2019
Messages
520
Likes
318
Fair enough for complex DSP, but attenuation is a trivial operation that any DAC can do just fine. Again, you need the extra precision only during the operation, not before or after.

If you re-read ESS's doc, doing the math and returning it back to 16-bits does lose precision.

"...
• Why worry about 23ppm at -10dB, and 866ppm at -35db?
Surely these are small errors?​
• No they are not small:
– 866ppm has degraded the performance of that 16 bit DAC by a factor of more than 50!​
• As a digital volume control operates on a fixed-width field (i.e. on that 16 bit number that the DAC receives) it creates noise because the DAC cannot make the fractional part of the number.
– And this is a large noise​
..."

Again, the reason for the 32-bit interface when using external software volume controls.
 
Last edited:

MC_RME

Addicted to Fun and Learning
Technical Expert
Audio Company
Joined
May 15, 2019
Messages
854
Likes
3,564
Not at all. 24 bit is more than enough. If you do these calculations at 24 bit depth on your computer all 'errors' will vanish deep in the noise floor of the DAC that outputs that 24 bit signal. If you talk about doing this in the DAC itself (like ESS doc), even a 16 bit interface as 'DAC input' is enough for high quality volume calculations at whatever resolution, as they happen after the DAC received the signal.

IMHO the ESS doc nowhere demands that DAC chips should have a 32 bit input data path. They just happen to have so as that is current technology. Your sources stay at 16 bit , or if you're lucky at 24 bit real resolution anyway.
 

g29

Addicted to Fun and Learning
Joined
May 1, 2019
Messages
520
Likes
318
...IMHO the ESS doc nowhere demands that DAC chips should have a 32 bit input data path. They just happen to have so as that is current technology. Your sources stay at 16 bit , or if you're lucky at 24 bit real resolution anyway.

The way I read it, the 32-bit input data path is implied (not demanded) to achieve identical results externally as internally. Their examples show doing volume control in 32-bits inside the DAC without loss, 16-bit with loss (e.g. 533.5372 gets rounded to 534), but does not specifically address doing it externally. If the same resolution math is to be accomplished externally in software, it follows it needs to have the same 32-bit resolution math used internally to do so (including float/integer), else it could be done in 16-bit both internally or externally without loss (they didn't directly address 24-bit resolution math). Their document states it can't be done in 16-bit without loss (e.g. 533.5372 gets rounded to 534). They don't show it being done in 24-bit with or without loss so that "loss" is TBD if it is the same as 32-bit or not.

As for if the loss is discernible or not, that is another issue. ESS seems to think it is significant, "866ppm has degraded the performance of that 16 bit DAC by a factor of more than 50! ... And this is a large noise".

@MC_RME , If you are a manufacturer of DACs, can you answer the question is external software volume control better, same or worse than analog volume controls?
 
Last edited:

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
The way I read it, the 32-bit input data path is implied (not demanded) to achieve identical results externally as internally. Their examples show doing volume control in 32-bits inside the DAC without loss, 16-bit with loss (e.g. 533.5372 gets rounded to 534), but does not specifically address doing it externally.

I think you are misreading it. The passage you quoted talks about using 16 bits for the calculation.
 

g29

Addicted to Fun and Learning
Joined
May 1, 2019
Messages
520
Likes
318
I think you are misreading it. The passage you quoted talks about using 16 bits for the calculation.
This half-precision float calculator truncates 533.5372 to 532 in 16-bit float (1 sign bit, 7 Mantissa bits, 8 exponent bits). I will try to find another 16-bit calculator to verify.

Half precision calculator
 
Last edited:

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
This half-precision float calculator truncates 533.5372 to 532 in 16-bit float (1 sign bit, 7 Mantissa bits, 8 exponent bits). I will try to find another 16-bit calculator to verify.

Half precision calculator

Why would anyone use 16 bit floating point? As you write, it only has 7 bit precision. 32 bit floating point has 24 bit precision, but with modern processors 64 bits is just as efficient. Anyway, audio tends to be integer - for a reason.
 

g29

Addicted to Fun and Learning
Joined
May 1, 2019
Messages
520
Likes
318
Why would anyone use 16 bit floating point? As you write, it only has 7 bit precision. 32 bit floating point has 24 bit precision, but with modern processors 64 bits is just as efficient. Anyway, audio tends to be integer - for a reason.

So if you go to a 16-bit integer format (16-bit interface), it truncates it to 533 or rounds it to 544, so you still have the error. Show me how to represent 533.5372 in 16-bits if you can. I am not able to do so without my bit stretcher.
 

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
So if you go to a 16-bit integer format (16-bit interface), it truncates it to 533 or rounds it to 544, so you still have the error. Show me how to represent 533.5372 in 16-bits if you can. I am not able to do so without my bit stretcher.

We seem to be talking past each other here.

Why does it matter? Again, what happens in digital volume control is that you take your 16 or 24 bit (integer) input, do the scaling in whatever intermediate format is natural for the processor (such as 64 bit floating point), and output 16 or 24 bits. No need to represent 533.5372 in 16 bits.
 

g29

Addicted to Fun and Learning
Joined
May 1, 2019
Messages
520
Likes
318
We seem to be talking past each other here.

Why does it matter? Again, what happens in digital volume control is that you take your 16 or 24 bit (integer) input, do the scaling in whatever intermediate format is natural for the processor (such as 64 bit floating point), and output 16 or 24 bits. No need to represent 533.5372 in 16 bits.

Must be. The OP was asking what he should set his output to be (16, 24 or 32). It seems if he does external software volume control and uses 16-bit output, the following happens.

If 533.5372 is the correct answer and it can NOT be accurately represented in 16-bits then it appears the interface needs to be larger than 16-bits to avoid loss (the answer to the OP's original question).
 

daftcombo

Major Contributor
Forum Donor
Joined
Feb 5, 2019
Messages
3,687
Likes
4,068
Not at all. 24 bit is more than enough. If you do these calculations at 24 bit depth on your computer all 'errors' will vanish deep in the noise floor of the DAC that outputs that 24 bit signal. If you talk about doing this in the DAC itself (like ESS doc), even a 16 bit interface as 'DAC input' is enough for high quality volume calculations at whatever resolution, as they happen after the DAC received the signal.

IMHO the ESS doc nowhere demands that DAC chips should have a 32 bit input data path. They just happen to have so as that is current technology. Your sources stay at 16 bit , or if you're lucky at 24 bit real resolution anyway.
So 16bit always enough except on Windows if you use Windows as volume control?
 

Julf

Major Contributor
Forum Donor
Joined
Mar 1, 2016
Messages
3,004
Likes
3,998
Location
Amsterdam, The Netherlands
Must be. The OP was asking what he should set his output to be (16, 24 or 32). It seems if he does external software volume control and uses 16-bit output, the following happens.

If 533.5372 is the correct answer and it can NOT be accurately represented in 16-bits then it appears the interface needs to be larger than 16-bits to avoid loss (the answer to the OP's original question).

So what you are saying is that 16 bits is only capable of 16-bit accuracy. Can't disagree with that. :)

But no, the interface doesn't need to be more than 16 bits - the output (and calculation) needs to be.
 
Top Bottom