What bit depth should I set my DAC to?

[g29]

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.

I interpret from the ESS doc's that the value 533.5372 is the correct output of the volume attenuation calculation example. The correct answer. If that answer was derived outside of the DAC using software volume control (using higher precision), please explain how that higher precision calculated output value can be passed through a 16-bit interface without losing accuracy? Dumb it down for me. How can you pass a higher precision number though a smaller precision keyhole without losing accuracy ?

 

[Julf]

I interpret from the ESS doc's that the value 533.5372 is the correct output of the volume attenuation calculation example. The correct answer. If that answer was derived outside of the DAC using software volume control (using higher precision), please explain how that higher precision calculated output value can be passed through a 16-bit interface without losing accuracy? Dumb it down for me. How can you pass a higher precision number though a smaller precision keyhole without losing accuracy ?

You can't - but you don't need to. If you have 16-bit source material, and a 16-bit DAC, why would you worry about a precision beyond 16 bits? You don't lose any accuracy - it is still 16 bits.

 

[Krunok]

The way I read it, the 32-bit input data path is implied (not demanded) to achieve identical results externally as internally.

Nope, it's not implied nor is necessary.

 

[Krunok]

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

Correct.

 

[g29]

You can't - but you don't need to. If you have 16-bit source material, and a 16-bit DAC, why would you worry about a precision beyond 16 bits? You don't lose any accuracy - it is still 16 bits.

With attenuation and then 16-bit truncation, you do introduce noise as plainly pointed out in the article. I asked you to plainly, dumb it down for me and demonstrate how do you pass a higher precision number through a lower precision keyhole without rounding or truncation which you have not done. If your response is, truncate or round it and forget about the errors, then so be it. On the other hand, if there is a mathematical explanation or proof, I would really like to see it.

"...
• 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
..."

 

[Julf]

With attenuation and then 16-bit truncation, you do introduce noise as plainly pointed out in the article.

And I pointed out that you misunderstood the article, and that they are talking about 16-bit processing vs. using larger temporary precision.

Specifically your quote from the presentation:

As a digital volume control operates on a fixed-width field (ie on that 16 bit number that the DAC receives) it creates noise because the DAC cannot make the fractional part of the number.

So they are talking about a fixed-width 16-bit field.

I asked you to plainly, dumb it down for me and demonstrate how do you pass a higher precision number through a lower precision keyhole without rounding or truncation ? If your response is, truncate or round it and forget about the errors, then so be it.

So I repeat, as plainly as I can: while you do need additional precision when actually performing the scaling calculation, you don't need more precision in or out than what the source material has.

 

[g29]

And I pointed out that you misunderstood the article, and that they are talking about 16-bit processing vs. using larger temporary precision.

Specifically your quote from the presentation:



So they are talking about a fixed-width 16-bit field.



So I repeat, as plainly as I can: while you do need additional precision when actually performing the scaling calculation, you don't need more precision in or out than what the source material has.

Again, you are throwing out the baby with the bath water. They use higher precision math to get a the correct answer in a higher precision larger container that does not have round off or truncation errors. Once that is stuffed back into a fixed-width 16-bit field, truncation and rounding occurs and are imposed. You have not demonstrated anything other than saying the errors get re-introduced when placed back into the fixed-width 16-bit field.

A bank can not cash your check of $533.54 using only dollar bills, no change and still be able to balance their books at night.

 

[Julf]

Again, you are throwing out the baby with the bath water. They use higher precision math to get a the correct answer in a higher precision larger container that does not have round off or truncation errors. Once that is stuffed back into a fixed-width 16-bit field, truncation and rounding occurs and are imposed.

Yes, at a precision that is the same as the original source material.

You have not demonstrated anything other than saying the errors get re-introduced when placed back into the fixed-width 16-bit field.

No, that is not what I am saying. Errors don't get "re-introduced".

You haven't demonstrated anything either, apart from keeping referring to that one document that you seem to misunderstand. I suggest you go back and read it again.

A bank can not cash your check of $533.54 using only dollar bills, no change and still be able to balance their books at night.

Great example - because monetary amounts are limited precision, to balance the books you have to round up to whole cents - and as you say, a bank can not cash your check of $533.54 using only dollar bills. They need the same precision (cents) as the input material (the check). They don't need 1/1000th's of a dollar to do that.

 

[g29]

Yes, at a precision that is the same as the original source material.



No, that is not what I am saying. Errors don't get "re-introduced".

You haven't demonstrated anything either, apart from keeping referring to that one document that you seem to misunderstand. I suggest you go back and read it again.



Great example - because monetary amounts are limited precision, to balance the books you have to round up to whole cents - and as you say, a bank can not cash your check of $533.54 using only dollar bills. They need the same precision (cents) as the input material (the check). They don't need 1/1000th's of a dollar to do that.

When you accurately attenuate the volume, you get a fraction that can not be represented in 16-bits. Same way 54 cents can not be represented in folding money. Let me restate my example so you don't play the 2 decimal points obfuscation again. This time, try cashing your $533.34 check using only $100 bills. As with the ESS example, you lose 4 decimal places with both examples. This time $33.34 throws the books more out of balance than 34 cents.

Again, missed/avoided/obfuscated the entire point. I interpret your consistent response as "ignore the rounding/truncation errors" caused by stuffing the accurate calculation into a fixed-width 16-bit container unable to acurrately represent it. If that is the point you are trying to get across, say so.

 

[Julf]

When you accurately attenuate the volume, you get a fraction that can not be represented in 16-bits. Same way 54 cents can not be represented in folding money. Let me restate my example so you don't play the 2 decimal points obfuscation again. This time, try cashing your $533.34 check using only $100 bills.

You really don't see what is wrong with your example?

Of course you can't cash a $533.34 check using only $100 bills. Just like you can't accurately reproduce 16-bit audio with only 8 bits.

Let's make this really simple. Let's assume we get rid of cents, and only use whole dollars. Three people agree to split the restaurant bill that just happens to be exactly $100. They do a quick calculation, and realize each one should pay 33 1/3 dollars. As we only deal with whole dollars, two of them pay 33 and one 34 - we have not lost any precision anywhere. Granularity / accuracy is still one dollar.

Again, missed/avoided/obfuscated the entire point.

Indeed, you did.

I interpret your consistent response as "ignore the rounding/truncation errors" caused by stuffing the accurate calculation into a fixed-width 16-bit container unable to accurately represent it. If that is the point you are trying to get across, say so.

Nice straw man. The calculation can never be more accurate than the input data, so the 16-bit output (not temporary container) is able to represent the result.

Remember, 1.0 / 3.0 is not 0.33333333333..... but 0.3, within original accuracy.

 

[g29]

You really don't see what is wrong with your example?

Of course you can't cash a $533.34 check using only $100 bills. Just like you can't accurately reproduce 16-bit audio with only 8 bits.

Let's make this really simple. Let's assume we get rid of cents, and only use whole dollars. Three people agree to split the restaurant bill that just happens to be exactly $100. They do a quick calculation, and realize each one should pay 33 1/3 dollars. As we only deal with whole dollars, two of them pay 33 and one 34 - we have not lost any precision anywhere. Granularity / accuracy is still one dollar.



Indeed, you did.



Nice straw man. The calculation can never be more accurate than the input data, so the 16-bit output (not temporary container) is able to represent the result.

Remember, 1.0 / 3.0 is not 0.33333333333..... but 0.3, within original accuracy.

The calculated result is more accurate than the input data (unless it is an even multiple). Divide 7 by 2 and see what you get. Not 3 and not 4 which you keep insisting is the "correct" answer.

 

[Julf]

The calculated result is more accurate than the input data. Divide 7 by 2 and see what you get. Not 3 and not 4 which you keep insisting is the "correct" answer.

Sorry, but 3 or 4 is the correct answer within the precision of the input data.

Am I correct in assuming you don't have a background in engineering, science or mathematics?

 

[g29]

Sorry, but 3 or 4 is the correct answer within the precision of the input data.

Am I correct in assuming you don't have a background in engineering, science or mathematics?

Please reread the ESS doc. Internally it is 32-bit, not 16-bit. They are doing the attenuation in 32-bit and keeping it there, not 16-bit. Your assumption of it going back to 16-bit appears to be the sticking point.

 

[Julf]

Please reread the ESS doc. Internally it is 32-bit, not 16-bit. They are doing the attenuation in 32-bit and keeping it there, not 16-bit. Your assumption of it going back to 16-bit appears to be the sticking point.

You can't keep it in 32 bits unless you have a 32-bit DAC. Nobody has.

 

[Julf]

Please reread the ESS doc.

Is that your only source?

 

[g29]

You can't keep it in 32 bits unless you have a 32-bit DAC. Nobody has.

Faux argument of omission ??? You neglect mentioning anything higher than 16-bit, yet they appear to exist ???

 

[Julf]

Faux argument of omission ??? You neglect mentioning anything higher than 16-bit ???

Not sure what your point is. In the very beginning of this thread I mentioned that the very best DACs have 21 effective bits. Anyway, you seem to be getting a bit agitated (the silly "???"s and ""s), and aren't addressing the points I am making, or answering my questions, so I guess we're done. Have a good day!

 

[g29]

Not sure what your point is. In the very beginning of this thread I mentioned that the very best DACs have 21 effective bits. Anyway, you seem to be getting a bit agitated (the silly "???"s and ""s), and aren't addressing the points I am making, or answering my questions, so I guess we're done. Have a good day!

I think you just made my point. The calculated value is NOT going back to 16-bit and is retaining higher precision than 16-bit. I think we have agreement on that. As for external software volume control, similar results should be able to be achieved externally by using a larger than 16-bit interface and not by using a 16-bit interface.

 

[Julf]

I think you just made my point. The calculated value is NOT going back to 16-bit and is retaining higher precision that 16-bit.

Until you attenuate enough...

As for external software volume control, similar results should be able to be achieved externally by using a larger than 16-bit interface and not by using a 16-bit interface.

Sure, but why would you? I think we already had this discussion. DACs are perfectly capable of handling attenuation, and some of them even have analog attenuation under DAC control.

 

[g29]

...
Sure, but why would you? I think we already had this discussion. DACs are perfectly capable of handling attenuation, and some of them even have analog attenuation under DAC control.

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.