WinSoftVol: force Windows software volume control

Brought to you by [Etienne Dechamps][] - [GitHub][]

Description

The goal of WinSoftVol is to stop Windows from using the hardware volume control that most audio devices provide, forcing Windows to use its own [software volume control][] mechanism instead. See also example use cases.

WinSoftVol takes the form of a [filter driver][] that can be inserted on top of any audio device driver. It works by intercepting hardware volume control queries from the Windows audio engine before they make their way to the audio device driver.

This project can also serve as a nice [code sample][] for a trivial, minimalistic [Kernel Streaming][] [WDF][] [filter driver][msfilter].

Why would I possibly want to use this?

That's a good question. To be honest, unless you find yourself in one of the example situations described below, it is unlikely you'd want to go through the hassle of deploying WinSoftVol. It is only useful in a very narrow set of scenarios.

Broadly, there are two main reasons why you'd want to use WinSoftVol:

• The volume control your hardware provides is unsatisfactory.
  • For example, some devices (e.g. FiiO E7) expose a volume control that doesn't work at all, leaving the Windows volume control inoperative.
• You want to exploit the fact that Windows software volume control operates on the same floating-point samples that the rest of the Windows audio engine (in particular, [APOs][]) operates on.
  • This can be used to [avoid clipping][] in some scenarios described in more detail below.

Using software volume control to avoid clipping in the Windows audio engine

A note about "clipping": this document uses the term "clipping" somewhat liberally. Technically the Windows audio engine never really lets its output "clip" because the final stage goes through a little-known limiting filter known as [CAudioLimiter][] right before conversion to integer. This filter mitigates the worse effects of clipping by redistributing the nasty-sounding harmonics so that they become likely to be masked by the human auditory system. Subjectively, CAudioLimiter appears to be quite effective at making clipping much more difficult to notice. This explains why "clipping" in the Windows audio engine output doesn't really sound like digital clipping at all - though obviously this filter is not magic and one can still tell that the signal level is being limited. To keep things digestible, this document uses the term "clipping" throughout, even though what is really meant is "limited by CAudioLimiter".

To understand how Windows software volume control can be used to prevent digital clipping in specific scenarios, you need to keep in mind the following:

• All Windows audio processing occurs inside the Windows audio engine. The Microsoft docs include a number of [diagrams][] that help visualize this. This processing notably includes:
  • Mixing audio from multiple applications playing at the same time;
  • APOs, for example [Equalizer APO][];
  • Software volume control, if hardware volume control isn't used.
• The Windows audio engine internally operates on 32-bit floating-point audio samples - not integer samples as you would find them on, say, a CD.
  • If an application sends integer samples, the first thing Windows does is convert them to floating-point first.
  • Windows converts between floating-point and the configured sample format for the device (e.g. 16-bit or 24-bit integer) as the very last step of processing (for playback) or the very first step (for recording).
• One fundamental difference between floating-point samples and the (way more commonplace) integer samples is that floating-point samples cannot clip. In other words, they have (virtually) infinite headroom.
  • This is because the "full range" of floating point audio samples is defined, by convention, as -1.0 to +1.0. But [floating-point][] can go much, much below -1.0, and much, much above +1.0. This means it is possible to exceed full range on floating-point samples without clipping. This is fundamentally impossible when using integer samples, because their "full range" is defined as the maximum range the chosen integer size can hold.
  • This is one reason why floating-point is a popular sample format for filter chains, such as those used in the Windows audio engine: they prevent clipping that could otherwise occur between the filters.

Now at this point you might be wondering where we're going with this. After all, these floating-point samples have to be converted to integer eventually so that a DAC can play them. Integer samples do not have infinite headroom, and neither does the DAC. Out-of-range floating-point samples will therefore clip as soon as they are converted to integer. So what is the point of all this?

The point is to make the volume control smarter by making it attenuate samples before they clip. Let me explain:

Detailed example scenario

Imagine you're using hardware volume control, as would be the case with most Windows audio devices. You're playing content that happens to be quite loud (i.e. low headroom), such as unnormalized popular music. Because it is loud, you lower the Windows volume control to compensate. That volume control is hardware, meaning it attenuates samples after they've been converted to integer and sent to your DAC.

Now, let's also assume that something in the Windows audio engine (e.g. an APO) increases the signal gain on top of that already "loud" content. The resulting floating-point samples are likely to exceed full range. Here's the problem: these out-of-range floating-point samples will stay out of range when the final conversion to integer is taking place and they will clip! Your audio hardware still has plenty of output level headroom available, but that extra headroom sits there unused because of the device's own hardware volume control.

[![Hardware volume control graph][hardvolgraph]][hardvolgraph]

"Okay", I hear you say, "well I'll just add some attenuation to the APO to prevent clipping then, no big deal". Sure, you could do that, but now you have the opposite problem. Let's say you're now playing "quiet" (i.e. high headroom) content, such as most movies or normalized music. The problem is, now the output is too quiet because of the attenuation you just added! Even with the volume control at 100%, the output level is still insufficient.

Now, of course you could just switch the attenuation on and off depending on which type of content you're playing. So, if you're playing "loud" content (with the volume control set low), you enable attenuation to prevent clipping, and if you're playing "quiet" content (with the volume control set high), you disable it to increase output level, knowing that because the content is quiet, it's unlikely to clip.

Obviously it would be quite annoying to have to toggle that attenuation all the time. But what if I told you that could happen automatically and transparently, in such a way as to always exploit the full dynamic range of the system, no matter what type of content you're playing?

This is what Windows software volume control does. When software volume control is used, the master Windows volume control does not act on the hardware. Instead it acts on a volume control APO that Windows automatically inserts inside the Windows audio engine, right before the samples are converted to integer - and therefore, before they clip. In other words, the Windows volume control itself replaces the "anti-clipping" attenuation we've described above.

[![Software volume control graph][softvolgraph]][softvolgraph]

Here's what happens when you use Windows software volume control:

• If you're playing "loud" content, with the volume control set low, floating-point samples in the Windows audio engine will be automatically and transparently attenuated, and thus prevented from clipping, by the software volume control APO.
• If you're playing "quiet" content, with the volume control set high and where clipping is unlikely, no unnecessary attenuation takes place and you get to use the full dynamic range of your audio hardware.

This is what WinSoftVol allows you to do. It forces Windows to ignore the "dumb" hardware volume control and to use its own "smart" software volume control instead.

Example use cases

If the above example doesn't resonate with you, here are some situations where clipping could be prevented by using software volume control:

• Volume boosting
  • If you are stuck with an audio device that has weak output (e.g. laptop speakers), you might be tempted to add some digital gain to the Windows audio pipeline (e.g. using [Equalizer APO][]) to compensate. That might give acceptable results when applications output "quiet" content, but it will clip horribly the moment you use an application that outputs "loud" (i.e. full range) content. (Actually it won't sound that bad thanks to CAudioLimiter, but still.)
  • In contrast, if you use software volume control, you can ensure the output will only clip when it actually exceeds the maximum hardware output level.
• Simplifying gain staging in APOs (e.g. EQ)
  • If you run APOs that do advanced signal filtering, such as audio EQ, you are probably familiar with the problem of avoiding clipping due to additional signal gain brought on by the filters.
  • WinSoftVol makes it possible to completely forget about this problem: you don't need any anti-clipping attenuation stage. Software volume control is the anti-clipping attenuation stage. The only limit becomes what the DAC can physically output, allowing you to use the full dynamic range of your system and simplifying your [gain structure][].
  • This is what I personally use WinSoftVol for. I us