• 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!

For those who worry about quality of software volume control

Krunok

Major Contributor
Joined
Mar 25, 2018
Messages
4,600
Likes
3,065
Location
Zg, Cro
I don't have a ESS DAC. If that ESS document is accurate, then I suppose it won't past the test.

I also think ESS volume control wouldn't pass your test as XU208 USB chip volume control works the same as ESS and it didn't pass. I also think ALSA library uses 32 bit integer precision and that is the reason why Volumio software volume control which uses ALSA also failed your test.
 

Nick Laslett

Member
Joined
Nov 6, 2019
Messages
26
Likes
13
I finally got round to trying the volume control test with bennetng‘s audio sample on my MiniDSP NanoAVR. Sadly to my surprise it failed the test.

*Edit due to my lack of understanding this could be due to other factors and not the MiniDSP. The Oppo 203 is converting the MP3 file to PCM before it is received by the NanoAVR
 
Last edited:

Daverz

Major Contributor
Joined
Mar 17, 2019
Messages
1,294
Likes
1,451
I hadn't looked at the test files up to now. Looking at them in Audacity, I can see that the test will fail with my "squeeze" setup because I downsample everything to 44100, and that will clip in this case, losing information (I don't actually stream any mp3s, but the principle is the same with flac). However if I attenuate 6 dB before resampling, it's OK. This is a pretty extreme example, and I think you can get away with less attenuation than that usually.
 
Last edited:
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,692
It's been a while since someone posted on this thread, but I was wondering if anyone has tried bennetng's test (below) with Roon, JRiver or Audirvana. I tried it with Audirvana both on a Mac and a Windows PC and was surprised to find that it failed on both.
I don't actually stream any mp3s, but the principle is the same with flac
No, they are fundamentally different. flac is an integer format. mp3, aac, vorbis, opus and the like are floating point formats. Read my previous replies to @Krunok on the earlier pages, and my article on Archimago's blog carefully to understand why. Krunok's replies are best examples that I asked people to read carefully but they didn't listen to me.
 

AudioExplorer

Member
Joined
Sep 13, 2020
Messages
33
Likes
13
No, they are fundamentally different. flac is an integer format. mp3, aac, vorbis, opus and the like are floating point formats. Read my previous replies to @Krunok on the earlier pages, and my article on Archimago's blog carefully to understand why. Krunok's replies are best examples that I asked people to read carefully but they didn't listen to me.

And now I tested with Roon as well and to my surprise it also didn’t pass this test. I am curious why this is the case.

@bennetng do you know why this may be the case even though Roon is showing conversion to 64 bit float before doing any headroom or resampling? Is it that fixed point is being used somehow in the way the mp3 is decoded in the first place?
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,692
Is it that fixed point is being used somehow in the way the mp3 is decoded in the first place?
Likely be the case, like this:
https://www.audiosciencereview.com/...-most-compliant-mp3-decoder.10886/post-304695

My article in Archimago's blog also contains this:
Even the non-audio specialized MPC-HC encourages internal volume attenuation. In the era of commercial streaming music services, there is really no excuse for the audio software/apps to not implement a floating point compliant processing pipeline when preparing masters and during playback.

There are also cases that the decoding is really done in floating point, but the software developers intentionally imposed a clipping threshold for some unknown reasons.

As for Audirvana, I don't use it, but is it somehow related to iZotope? Then read this:
https://izotope-rx.livejournal.com/5760.html?thread=1920#t1920

BTW, I am making an experimental audio format, and it is somehow related to the integer vs float topic:
https://hydrogenaud.io/index.php?topic=121181.msg1001671#msg1001671
The previous posts on thread explained what the software does, and the thread is only 2 pages long, so please read them to understand what we were talking about.
 

elole

Member
Joined
May 25, 2021
Messages
45
Likes
20
How about equalizer apo? is it a good software volume control? I tried the test but wasapi event just bypasses eapo.
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,692
The prerequisite is that the playback software is capable of unclipped decoding and unclipped output to the Windows mixer so that EAPO can intercept unclipped output from the playback software. After this it is more about the settings of EAPO on that "debate" thread.
 

edechamps

Addicted to Fun and Learning
Forum Donor
Joined
Nov 21, 2018
Messages
910
Likes
3,620
Location
London, United Kingdom
I realize that the tool I just wrote, WinSoftVol, seems highly relevant to this thread, so consider this a shameless plug in case anyone is interested.

In a nutshell: it's a Windows driver that can be used to disable hardware volume control on any audio device, forcing Windows to use software volume control instead. If anyone is wondering why I could possibly want to do this, well, I was able to come up with a pretty long list of reasons, although most of them won't apply to most people.
 

BeerBear

Active Member
Joined
Mar 9, 2020
Messages
264
Likes
252
That's interesting.
I tried to reproduce it with an analog (DA-AD) loopback. On the spectrum analyzer I saw what looked like noise (a couple of extra peaks) from the Windows limiter in shared mode at 0 dB. However, lowering the main Foobar volume to -0.5 dB got rid of it, same as if lowering it through the ReplayGain preamp.

Exclusive mode didn't have this visible noise at 0dB. It was, however, just slightly audibly noisier. Both modes (shared and exclusive) sounded like they had some clipping at 0dB, even though the test file (1kHz sine) maxes at -0.1 dBTP. It could be an anomaly of my sound card, I guess. Lowering the volume to -0.5 dB got rid of this clipping noise in both modes and made the spectrum look cleaner.
 

BeerBear

Active Member
Joined
Mar 9, 2020
Messages
264
Likes
252
Just to be sure, I tested with another sound card (Apple dongle). The clipping that I heard at 0 dB is gone. So, indeed, it looks like that was just a problem of the first sound card (Behringer UMC204HD). IIRC, the Behringer even has the output level set to 98% on a fresh install of the driver (I didn't pay much attention to it at the time, but I remember something like that).

The rest looked the same with the Apple. That is; shared mode has some extra peaks in the spectrum at 0dB compared to exclusive mode. But unlike what bennetng showed in the video, for me lowering the main Foobar volume in shared mode got rid of it, just like with the ReplayGain preamp. The difference is probably because Foobar changed something since that test by bennetng. I can see that the changelog for version 1.4 says "Integration with Windows 10 Universal Volume Control.", for example. I also think Foobar no longer uses DirectSound (in W10).

I noticed another thing. I tested with 16 and 24 bit test tones and the 24 bit one produced this (Windows limiter) noise in shared mode, while the 16 bit didn't, even if it was slightly higher in amplitude. At 0 dB the 16 bit file did produce that noise too, however.

24 bit file (-0.1 dB):
24.png


16 bit file (-0.01 dB):
16.png



Notice the two peaks to the left and right of the 1k Hz signal, for example. That's how this Windows limiter noise (?) looks like for me. The above two pictures are also how the shared vs exclusive modes look at full volume, playing the 24 bit file.

I'm attaching the test tones too, if anyone wants to have a look.
 

Attachments

  • 1kHz test tones, 16 and 24 bit.zip
    339.3 KB · Views: 40
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,692
The change was made in foobar2000 1.6. When I was still using 1.5.x the problem was still there.
Starting from version 1.6 the ReplayGain preamp hack is no longer necessary.
 

BeerBear

Active Member
Joined
Mar 9, 2020
Messages
264
Likes
252
That's good to know.
Meanwhile, I realized that I don't need a physical loopback to test this limiter distortion; it can be done with a Wasapi loopback in Reaper or Audacity. Of course, only shared mode can be tested this way.

So we can see that the 16 bit file does in fact have some distortion at -0.01 dB:
16 -0.01.png


And at -0.2 dB it's gone:
16 -0.2.png

(The other spikes are truncation noise, because I didn't use dither.)

There's still a difference in how 16 and 24 bit files are treated by the Windows limiter, but it's very small and probably not of practical importance.
 

dvcpro100

Member
Joined
Jan 3, 2022
Messages
10
Likes
0
Location
SF Bay Area, US
That's good to know.
Meanwhile, I realized that I don't need a physical loopback to test this limiter distortion; it can be done with a Wasapi loopback in Reaper or Audacity. Of course, only shared mode can be tested this way.

So we can see that the 16 bit file does in fact have some distortion at -0.01 dB:
View attachment 178453

And at -0.2 dB it's gone:
View attachment 178454
(The other spikes are truncation noise, because I didn't use dither.)

There's still a difference in how 16 and 24 bit files are treated by the Windows limiter, but it's very small and probably not of practical importance.
Which software did you use in the photos? Also what is this the windows limiter? Never heard anyone mentioned before.
 

BeerBear

Active Member
Joined
Mar 9, 2020
Messages
264
Likes
252
I noticed another thing. I tested with 16 and 24 bit test tones and the 24 bit one produced this (Windows limiter) noise in shared mode, while the 16 bit didn't, even if it was slightly higher in amplitude.
Since I can't edit my old posts anymore: That mysterious small difference was caused by a weird bug/inconsistency in the signal generating software that I used at the time. So nothing to see there, move along.

Which software did you use in the photos?
I used foobar2000, Reaper and SPAN.
For generating the (sine wave) test tones, you can use Audacity. The generator doesn't let you set the level in dB, but you can put a value like 0.999. And in Foobar you can use the Amplifier DSP to raise/lower the volume by small amounts.
 

abm0

Active Member
Forum Donor
Joined
May 12, 2019
Messages
126
Likes
58

edechamps

Addicted to Fun and Learning
Forum Donor
Joined
Nov 21, 2018
Messages
910
Likes
3,620
Location
London, United Kingdom
It seems delta-sigma DAC architecture also provides some arguments for preferring software/digital volume control: https://www.itsonlyaudio.com/audio-hardware/the-case-for-digital-volume-control/

I generally agree with that article with just one caveat: it's a bit one-sided because it doesn't mention that DACs can have linearity issues, which manifest as increased distortion at low digital levels. This is a potential problem when driving a DAC at very low volume. (Hence why @amirm measures linearity in his DAC reviews.) I do agree though that, in general, digital volume control is likely a net positive in many cases. I suspect near-0dBFS issues like intersample overs (which are mostly avoided when using digital volume control) would be much more audible than DAC non-linearity, unless the DAC is truly horrible (but then you have other problems).
 
Top Bottom