Vista volume control [translation]_vista

Original: Https://blogs.msdn.com/larryosterman/archive/2005/12/15/504158.aspx
Author: Larryosterman
Tony Qu (from Blueprint translation team)

Prior to Vista, all control of the application was system--when you change the volume with the Wave Volumn API, you change the volume of the hardware (sound card) at the same time, thus affecting all applications in the system. The problem with this is that for most applications this is a completely wrong behavior. This behavior is the traditional behavior of the old Windows 3.1 audio architecture, and in the Windows 3.1 audio architecture, only one application is allowed to play the sound at the same time, and in this case it makes sense because there is only one hardware volume.

After the Win98 WDM audio driver was released, Microsoft added a kernel-mode audio mixer, but he made the volume control architecture Independent. The volume control that the Windows API can do is still hardware volume control, the reason for this is simple: although each application does require a separate volume control, in the Win98 architecture, a separate audio stream cannot be associated with a particular application as a replacement, and the audio stream is handled separately.

In fact, most applications do need to control the volume of their audio streams individually, and they don't want (and don't need) to mix with other applications, which is actually a very bad side effect of the audio architecture.

For some applications, we do have a solution. For example, if you are using DirectSound (or DirectShow, in fact, DirectShow is based on DirectSound), you can send your audio into an auxiliary buffer because the Dsound auxiliary buffer has its own volume control, This will effectively provide separate volume control for each application. However, this is not helpful for applications that do not use DirectSound, they can only rely on tuning the hardware volume.

For Vista, one thing is deployed as part of the new audio architecture, which is the component, called the audio policy. One of the tasks of the policy engine is to track which audio stream belongs to which application.

In Vista, each audio stream is associated with an "audio session" (audio session), which is associated with a process (each process can have multiple audio sessions, and an audio session can span multiple processes), but by default, Each audio session is a collection of audio streams in the current process.

Each audio session has its own volume control, and WASAPI provides an interface that allows the application to control the volume of an audio session. The Volume Control API also includes a notification mechanism so that applications that need to be notified when the volume control changes are implemented-a mechanism that allows applications to know when other people are changing the volume.

It's all perfect, but in that case, should we be dealing with programs that already use the hardware volume control but don't want to use the hardware volume control?

Remember what I said, all of the existing APIs have been ported to use WASAPI directly. We also ported the volume control APIs to the volume control interface using WASAPI.

We also changed the Mixerline API to use WASAPI. This is slightly more complicated because the Mixerline API also requires us to define the layout of an audio device (topology), but we have defined a relatively simple layout that should match existing hardware technologies (all AppCompat should not be a problem)

The result: By default, in Vista Beta 2, we will first provide every application (per-application) volume Control for all applications