Volume control in Vista

Before Vista, all of the controls available to applications were system-wide - when you changed the volume using the wave volume APIs, you changed the hardware volume, thus effecting all the applications in the system.  The problem with this is that for the vast majority of applications, this was exactly the wrong behavior.  This behavior was a legacy of the old Windows 3.1 audio architecture, where you could only have one application playing audio at a time.  In that situation, there was only one hardware volume, so the behavior made sense.

When  the WDM audio drivers were released for Win98, Microsoft added kernel mode audio mixing, but it left the volume control infrastructure alone.  The volume controls available to the Windows APIs remained the hardware volume controls.  The reason for this is pretty simple: Volume control really needs to be per-application, but in the Win98 architecture, there was no way of associating individual audio streams with a particular application, instead audio streams were treated independently.

The thing is, most applications REALLY wanted to just control the volume for their audio streams.  They didn't want (or need) to mess with other apps audio streams, that was just an unfortunate side effect of the audio architecture.

For some applications, there were solutions.  For instance, if you used DirectSound (or DirectShow, which is layered on DirectSound), you could render your audio streams into a secondary buffer, since DSound secondary buffers had their own volume controls, that effectively makes their volume control per-application.   But it doesn't do anything to help the applications that don't use DSound, they're stuck with manipulating the hardware volume.

 

For Vista, one of the things that was deployed as part of the new audio infrastructure was a component called "Audio Policy".  One of the tasks of the policy engine is tracking which audio streams belong to which application.

For Vista, each audio stream is associated with an "audio session", and the audio session is roughly associated with a process (each process can have more than one audio session, and audio sessions can span multiple process, but by default each audio session is the collection of audio streams being rendered by the process).

Each audio session has its own volume control, and WASAPI exposes interfaces that allow applications to control the volume of their audio session.  The volume control API also includes a notification mechanism so applications that want to be notified when their volume control changes can implement this - this mechanism allows an application to track when someone else changes their volume.

This is all well and good, but how does this solve the problem of existing applications that are using the hardware volume but probably don't want to?

Remember how I mentioned that all the existing APIs were plumbed to use WASAPI?  Well, we plumbed the volume controls for those APIs to WASAPI's volume control interfaces too. 

We also plumbed the mixerLine APIs to use WASAPI.  This was slightly more complicated, because the mixerLine API also requires that we define a topology for audio devices, but we've defined a relatively simple topology that should match existing hardware topologies (so appcompat shouldn't be an issue).

The upshot of this is that by default, for Vista Beta2, we're going to provide per-application volume control for the first time, for all applications.

There is a very small set of applications that may be broken by this behavior change, but we have a mechanism to ensure that applications that need to manipulate the hardware volume using the existing APIs will be able to work in Vista without rewriting the application (if you've got one of those applications, you should contact me out-of-band and I'll get the right people involved in the discussion).

Comments

• Anonymous
  December 15, 2005
  I watched your most recent Channel 9 Vid and I thought the architectural details were really interesting. I thought of two questions about it:
  
  1. The user-mode mapped DMA memory sits in the svchost which contains WASAPI, right? How much memory copying has to go on to get rendered audio into that and how does WASAPI efficiently inform the soundcard that it's time to grab that data.
  
  2. The mixing seems to be done in software. Can WASAPI also take advantage of mixing hardware in the soundcard? Maybe I have some misconceptions and such mixers don't exist for PCM in hardware.
  
  Thanks for doing the interview.

• Anonymous
  December 15, 2005
  Are the settings of each such "audio sessions" going to be persisted? Or will I be able to control the volume for each app individually but it will reset to some default every time I close and restart that application? If the settings are going to be persisted what is going to be the key to those, process name?

• Anonymous
  December 15, 2005
  The comment has been removed

• Anonymous
  December 15, 2005
  I think both kinds of volume controls are needed, because 10% of the time the user really wants to adjust and/or mute their overall volume and the other 90% of the time the user wants each application to remember its own settings (i.e. the user doesn't want to repeat those settings 90% of the time). At least each application should be able to make it clear to the user which kind of setting is being done at each time.
  
  Compare this to keyboard input. Switching Caps Lock on or off applies to all applications in the PC (except for terminal services clients, and sometimes Virtual PC gets funnied), but switching IME modes applies only to an individual application. Users can get used to this inconsistency and double-check each time they switch applications. It would be better if the user could specify how widely they want each change to be applied.

• Anonymous
  December 15, 2005
  The comment has been removed

• Anonymous
  December 15, 2005
  Btw, Norman, your comment is 100% spot on and consistent with our designs.
  

• Anonymous
  December 15, 2005
  Many keyboards come with volume up/down/mute buttons. For all but couple applications they change the global mixer settings, but when the couple specific apps are active, they control just that applications volume. (WinDVD is such case I believe)
  
  Is there any changes in the keyboard volume control behaviour?

• Anonymous
  December 15, 2005
  Do you have some specs/sdk about WASAPI? Which functions are available? (Despite old mixerxxx functions)

• Anonymous
  December 16, 2005
  Joku, we've plumed the HID volume messages handled by the shell to talk to the hardware volume interfaces.
  
  For WinDVD, in XP it controls the hardware volume - it's a great example of an application that doesn't need to control the master volume but does.
  
  The SZ: Yes, specs will be forthcoming, they're in review right now and should be available by Beta2.
  

• Anonymous
  December 16, 2005
  The comment has been removed

• Anonymous
  December 16, 2005
  Skywing, there's no UI (that would be too hard). You need to install an appcompat shim to have the mixer APIs use the hardware.
  
  We've not yet found any application that needs to use the hardware volume, btw, it's my expectation that the number of apps that will need to be shimmed could probably be counted on one persons fingers and toes (I may be wrong, but it's not likely to be many).
  

• Anonymous
  December 25, 2005
  The comment has been removed

• Anonymous
  December 26, 2005
  Joku, we know. That version of the volume UI used a custom slider control, in the current builds, we've changed to using the slider common control and the behavior should be much more reliable.
  

• Anonymous
  January 03, 2006
  What about Windows NT 3.x?

• Anonymous
  January 24, 2006
  The comment has been removed

• Anonymous
  January 24, 2006
  The comment has been removed

• Anonymous
  January 25, 2006
  Finally!
  
  This will mean I can finally turn down Media Center and that it won't turn down my Skype session - that's always been REALLY annoying! Glad to hear there are some decent changes on the way.

• Anonymous
  January 25, 2006
  The comment has been removed

• Anonymous
  February 01, 2006
  The comment has been removed

• Anonymous
  February 01, 2006
  Adahn, the keyboard controls still work and still control the master volume.
  

• Anonymous
  February 16, 2006
  I am kiran Kumar S, working on audio driver. I tested my old driver written for Win XP. Previously there were 2 paths for the volume control.
  1. Mixer Control.
  2. Hardware Vol Control.
  
  I found that only one path from Mixer Control is working and the second path is not working. now in vista how do i get the control for the Hardware Volume That i used to get from Per Application Basis.
  
  
  

• Anonymous
  October 24, 2006
  PingBack from http://mediacenter.mattgoyer.com/archives/2006/01/13/1055

• Anonymous
  March 18, 2007
  PingBack from http://www.istartedsomething.com/20070319/little-things-add-up/

• Anonymous
  August 08, 2008
  PingBack from http://alt-tab.com.ar/el-control-de-volumen-de-windows-vista/

• Anonymous
  January 20, 2009
  PingBack from http://www.hilpers.com/229056-sound-mixer-in-vista