The final truth about DSP Volume Control in Roon

[dc655321]

That’s rather obvious isn’t it.. a digital volume control is never bit perfect .

If it were obvious to all we would not have threads like this one

 

[Dave Tremblay]

The problem with the above implementation is the writing of the file. You're truncating the bits when writing out a 16 bit PCM file. That is why we often prefer using floating point, even in WAV files, in the pro audio space. In a floating point number (total 32 bit number), you have a 24-bit number that preserves precision as you apply gain changes. The gain changes typically hit the exponent value. Eventually, your DAC is going to want PCM data, likely 24 or 32 bit, with a good DAC, you don't truncate those bits until right before the DAC, so any gain changes or DSP are not affecting your precision.

I mentioned above that the checksum could only be maintained if gain is applied as a factor of two. That is related to the way floating point numbers work. But even if it's nota power of two, the differences would be down below the noise floor of the DAC. No single DAC solution that I'm aware of exceeds 22 bits of precision, so you have two bits down there for some numerical rounding issues.

 

[dc655321]

The problem with the above implementation is the writing of the file. You're truncating the bits when writing out a 16 bit PCM file

Sure. You noticed the "naive" qualifier, right?
I believe there is also (re-)dithering going on in those commands I posted, fwiw...

The gain changes typically hit the exponent value.

I mentioned above that the checksum could only be maintained if gain is applied as a factor of two.

No disrespect, but these are also naive statements.

 

[DualTriode]

The weakest part in most playback chains is still the power amplifier. This is true even though there are some very good devices on the market today. The problem is even with an analogue volume control you cannot attenuate noise of this device. Most DACs have better figures than the power amplifiers. This means running the DAC right in front of the power amp there is no improvement by the analogue volume control at all.

So, you are all right in writing "... that it's already too loud at 10%, can't be good". I addressed it on the last page of my writing with:

"Another important point is that your power amplifier and your speakers should match. If the
perceived volume is inacceptable high running the amplifier without volume attenuation
either the amplifier is too strong for the speakers or the speakers are too sensitive for your amplifier."

Hello All,

Keep in mind that most crossovers placed after the power amplifier have attenuating L-Pads for midrange and Tweeters. The L-Pad attenuates the loudness including amplifier hiss. Crossover capacitors block DC that could destroy mids and tweeters.

Thanks DT

 

[Dave Tremblay]

Understood. It is a fairly complex issue and we're all trying to simplify to keep it clear.

 

[bennetng]

@dc655321 @Dave Tremblay

If my 16 bit signal were a data file with a checksum or hash, and we go through DSP to change the volume, then somehow remove only the changes from the file that were related to the volume change, would the new 16 bit file pass the checksum or hash?

Try this:

sox -V -b 16 -n test.wav synth 10 sin 3000 gain -1

Which generates a 16-bit 48kHz test file with a 3kHz tone at -1dBFS. The -V switch shows what SoX did step by step like this:

sox:      SoX v14.4.2
sox INFO nulfile: sample rate not specified; using 48000

Input File     : '' (null)
Channels       : 1
Sample Rate    : 48000
Precision      : 16-bit
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no


Output File    : 'test.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 16-bit
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comment        : 'Processed by SoX'

sox INFO sox: effects chain: input        48000Hz  1 channels
sox INFO sox: effects chain: synth        48000Hz  1 channels
sox INFO sox: effects chain: gain         48000Hz  1 channels
sox INFO sox: effects chain: dither       48000Hz  1 channels
sox INFO sox: effects chain: output       48000Hz  1 channels

Then turn down test.wav 33dB with and without dithering, with 24-bit output:

sox -V %1 -b 24 "%~dp1%~n1 truncate -33.wav" gain -33
sox -V %1 -b 24 "%~dp1%~n1 dither -33.wav" gain -33 dither

Then open the two converted files in Deltawave. As expected, the truncated file (white) exhibits distortion.

Then turn up both files 33dB and convert to 16-bit again, and force disable dithering with the -D switch:

sox -V %1 -b 16 -D "%~dp1%~n1 +33.wav" gain 33

sox:      SoX v14.4.2
sox INFO formats: detected file format type `wav'
sox INFO wav: EXTENSIBLE

Input File     : 'E:\download\volume\test truncate -33.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 24-bit
Duration       : 00:00:10.00 = 480000 samples ~ 750 CDDA sectors
File Size      : 1.44M
Bit Rate       : 1.15M
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

sox INFO sox: Overwriting `E:\download\volume\test truncate -33 +33.wav'

Output File    : 'E:\download\volume\test truncate -33 +33.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 16-bit
Duration       : 00:00:10.00 = 480000 samples ~ 750 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comment        : 'Processed by SoX'

sox INFO sox: effects chain: input        48000Hz  1 channels
sox INFO sox: effects chain: gain         48000Hz  1 channels
sox INFO sox: effects chain: output       48000Hz  1 channels

As you can see, the truncated file and dithered file are identical to original file when you turn up the volume again.

MD5sums 1.2 freeware for Win9x/ME/NT/2000/XP+
Copyright (C) 2001-2005 Jem Berkes - http://www.pc-tools.net/

[Path] / filename                              MD5 sum
-------------------------------------------------------------------------------
[E:\download\volume\]
test dither -33.wav                            8603b8d9a23585dbb7a67d362a9a1a55
test truncate -33 +33.wav                      639fb1971da1ad3ccf1613090213bc26
test truncate -33.wav                          e84ddb9589c49a09b06b0356e28893d5
test.wav                                       639fb1971da1ad3ccf1613090213bc26
test dither -33 +33.wav                        639fb1971da1ad3ccf1613090213bc26

BTW, MD5 is not a "secure" hash anymore, to be absolutely sure one should compare the files bit by bit like this:
https://www.foobar2000.org/components/view/foo_bitcompare
It only checks the audio data within the files, so things like metadata won't affect the results.

What does it mean? A test like this cannot be used to evaluate the quality of a digital volume control. You are sending the modified bits (the 24-bit files) to the DAC, not the reverted 16-bit files. In this example, the truncated 24-bit file indeed has higher distortion.

At the end, 32-bit float has 25 bits of precision, not 24. Every time I see people say 24 I will make a correction.
https://www.audiosciencereview.com/...table-field-recorder-review.15668/post-507610

 

[voodooless]

BTW, MD5 is not a "secure" hash anymore,

That doesn’t mean you can’t use it to compare files. You just should not use it for security applications. Reason is that you can doctor a hash. So you can alter a file to get a specific hash. Since you generate the hashes on your own file, there is no issue. Chance of getting the same hash are next to nothing. Doing a bit for bit compare is therefore not needed (would need less computing resources though ).

 

[stevenswall]

That’s rather obvious isn’t it.. a digital volume control is never bit perfect .

Except at the max volume, right? (No attenuation.)

Also, even though it wouldn't pass a checksum, couldn't a digital volume control increase the bit depth, and losslessly vs the original file change the volume up and down?

Or is that thwarted because the noose floor would then be at a different ratio, so now you don't have the original audio anyway?

I think I answered my own question.

With noise floor though, does that apply to midi? I wonder if there is a way an AI could store music where you could adjust the volume and re-encode all you want but the bass data is "play a trumpet sound like this at XdB relative to the choir," etc and now we have a perfect recreation available at any volume. Kind of like a vector format does for images. Just depends on the resolving power if the presenting medium.

 

[Dave Tremblay]

Kind of a divergent topic, but what is your intuition on 25 bits for floating point? I believe that the IEEE spec is a 23 bit mantissa, 8 bit exponent, and 1 sign bit. That would simplistically give you 24 bits of precision when comparing to something like fixed point. I could possibly see how the lowest exponent bit could be considered an additional bit. Thoughts?

 

[voodooless]

Except at the max volume, right? (No attenuation.)

Yes, like a broken clock being correct twice a day

 

[bennetng]

Kind of a divergent topic, but what is your intuition on 25 bits for floating point? I believe that the IEEE spec is a 23 bit mantissa, 8 bit exponent, and 1 sign bit. That would simplistically give you 24 bits of precision when comparing to something like fixed point. I could possibly see how the lowest exponent bit could be considered an additional bit. Thoughts?

My previous reply has a test file. So everyone can try to convert the 32-bit float file to 24-bit integer file and examine the difference.
https://www.audiosciencereview.com/...table-field-recorder-review.15668/post-507610

Also this. So not only me. The authors of SoX also say 25 bits. For an apple to apple comparison in audio formats, it is the fact.
https://www.audiosciencereview.com/...depth-should-i-set-my-dac-to.8956/post-255104

 

[DrCWO]

I would like to inform you that I have updated my whitepaper with further measurements.

I received a circuit board with an XMOS from HIYINHK and measured the implementation of the digital volume in their XMOS firmware. I took the measurements so that they are comparable to my measurements of the Roon DSP volume.

The result is amazing:
With XMOS device volume, Roon shows me a purple dot as a sign of lossless playback. I get a green dot when using the Roon DSP volume. However, the measurements show that the noise floor of the digital XMOS volume is 20 dB above that of the Roon DSP volume ;-)

So if you have a DAC with XMOS device volume, you'd better use the ROON DSP volume despite the green dot.

 

[voodooless]

Not every XMOS is the same. They might just have implemented a crappy one, or the default XMOS volume control code is crappy. Either way, it’s software, so one could implement a better one.

 

[DrCWO]

See my paper. Citation:
"I have no knowledge if the manufacturers use exactly this firmware or modify it.
So, the measurements presented here are only valid for this PCB from DIYINHK."

There is no dither in this XMOS implementation. I doubt in the XMOS chip there is not enough memory to calculate a long enough (ron repeating) random sequence of numbers.

 

[JohnYang1997]

You just need a digital volume control that's 2bits higher than the actual equivalent bits of the DAC. 24bit fixed point is good enough.

 

[voodooless]

I doubt in the XMOS chip there is not enough memory to calculate a long enough (ron repeating) random sequence of numbers.

There is no need for memory. You can have a very good pseudorandom generator with various distributions with a few dozen lines of code.

 

[boXem]

Didn't know that doing random tests without understanding the background science neither analysing the results or doing any research on the state of the art and doing a bunch of citations could be called a white paper. Good to know.
I'm out for lunch with family, I may publish a white paper about the main dish tomorrow. Stay tuned!

 

[Dave Tremblay]

https://www.audiosciencereview.com/...table-field-recorder-review.15668/post-507610
Also this. So not only me. The authors of SoX also say 25 bits. For an apple to apple comparison in audio formats, it is the fact.
https://www.audiosciencereview.com/...depth-should-i-set-my-dac-to.8956/post-255104

Not doubting you, just looking for a clear explanation of where it’s coming from. I’ve been doing floating point DSP for audio products for 25 years, so I’m intimately familiar with the format. 23 bits in the fractional part (mantissa) plus the sign bit, for total of 24 bits before you start using the exponent and potentially truncating precision. I suspect that 25th bit is coming from an implicit assumption in the exponent, but I haven’t ever really investigated that. Just curious.

 

[Dave Tremblay]

For clarity, there is an implicit 1 in the mantissa that isn’t stored. The IEEE spec requires it. If the value is smaller, the FPU will left shift the mantissa until there is a 1, and add those shifts to the exponent. That is probably where this is coming from…

 

[bennetng]

Not specific to any post on this thread... for the usual comments came up countless times on every audio forum that no DAC can achieve more than 22 bit DNR, fixed vs floating point and the like, I think I should link to another comment I posted before:
https://www.audiosciencereview.com/...-bit-perfect-volume-control.19919/post-665246

...as well as this:
https://www.audiosciencereview.com/...y-of-software-volume-control.5922/post-172865