Programatically setting the default playback device (and recording device)

Programatically setting the default playback device (and recording device)

• rtmurray

  Thanks for the info, Larry.
  
  I think we cross-posted because I didn't see your post when I started my last reponse.
  
  It's true there wasn't previously an api to change the default device, but the OS did not prevent us from setting our device's audio path (under XP, we can control the recording source by setting the value of a Mux control). Under Vista we can set the input line of the mux control all we want, but as soon as someone starts recording, the value is changed (as it should be).
  
  This is all as it should be; the Vista audio model focused on the actual "endpoints" that users interact with is a nice improvement over the old method. We'd just like full access to the user settings that control this model. Remember, we don't want to take control of the user's setting--but rather to give them an alternate, more powerful and more convenient access to those settings.
  
  Anyway, I realize this is all moot right now since the api calls don't exist at this point, I just wanted to get my argument out there that there are some good reasons to allow this sort of thing.
  
  Thanks for your help and consideration. I do appreciate it.

  Vista does allow developers to access the individual controls on the audio device (like the mux) control, if you look at the IDeviceTopology interface, you can see how to interact with the mux controls (and all the other controls on the device). Vista provides full support for ISVs modifying the state of all the controls on the audio solution. One caveat: Vista will automatically switch the mux to the users capture endpoint when they start capturing on the endpoint (regardless of the original setting of the mux). This was done to simplify the design of audio capture applications.

  
  

• codeberg

  Larry Osterman wrote:

  Microsoft DOES provide a mechanism for a new audio device to indicate that it should be the preferred device, this is typically used for USB audio devices.

  
  
  When we connect our USB audio device to a Vista machine, Vista automatically sets it to be the default audio device. We would like Vista not to change the default device. (From this discussion, I would've thought that Vista's default would be not to make new devices the default, but it doesn't seem to work that way.) On XP, we could change the Registry values back to what they were, but as you say, that won't work on Vista. Your post suggests we can tell Vista not to make the new device the default, and I'd be interested in knowing how to do it. I assume it'd be in the INF, but I can't find documentation on the mechanism.
  
  

• mohd sufian

  I don't think so, but I will check again when I have time.

  Regards,

  
  
  

• idar

  Hi vtb,

  There is no way to do this programmatically. This is a deliberate design, since we do not want applications to override audio setting set by the user.

  
  
  

• Sammaye

  Hi John,

  This has been a fairly common request over the various versions of Windows -- common enough to convince me that making a public "SetPreferredAudioDevice" API is not the right thing to do. We do trust external developers and we are quite confident that in the absense of any other audio devices on the machine they would do the right thing. However, we also must ensure a decent Windows experience for users who have multiple audio devices.

  Consider the case where a user has two audio devices A and B, from two different manufacturers. Device A has a service that employs some clever use of "SetPreferredAudioDevice" for switching between it's audio endpoints based on plug insertions or usage profile changes or what-have-you. It's not hard to imagine the service for device A accidentally making device B practically useless. If both devices have utilities or services that change the default device (again with no malicious intent by either) the potential for conflict becomes greater. Pretty much every computer with a webcam, USB headset or array mic has audio devices from at least two different manufacturers.

  By providing a means of extending the "Sound" control panel (mmsys.cpl), we hope to eventually consolidate audio hardware settings in one place. For info on writing a UI extension page for mmsys.cpl, please see the WDK "AC97 Proppage" sample.

  Regards,

  Mitch Rundle (MSFT)

  
  

• Andrew Raymond

  Can you write a Control Panel extension which exposes all your features through the Vista Audio Control Panel. This way the customer will have to go to only one place ( The Vista Control Panel ).

  Here is some overview of the APIs you can use: http://blogs.msdn.com/larryosterman/archive/2005/09/23/473351.aspx

  
  
  

• megoo80

  Sorry for the late reply...

  << The call should only fail if another endpoint on the device is actually in active use (in which case I want the call to fail, of course). >>

  That's exactly how it is designed to work, so something else must have been recording. Did you have the control panel open when you were experimenting It captures from every capture endpoint that it can in order to show the meters.

  Regards,

  Mitch

  
  

• Tommmy77

  Thanks for the info, Larry.
  
  I think we cross-posted because I didn't see your post when I started my last reponse.
  
  It's true there wasn't previously an api to change the default device, but the OS did not prevent us from setting our device's audio path (under XP, we can control the recording source by setting the value of a Mux control). Under Vista we can set the input line of the mux control all we want, but as soon as someone starts recording, the value is changed (as it should be).
  
  This is all as it should be; the Vista audio model focused on the actual "endpoints" that users interact with is a nice improvement over the old method. We'd just like full access to the user settings that control this model. Remember, we don't want to take control of the user's setting--but rather to give them an alternate, more powerful and more convenient access to those settings.
  
  Anyway, I realize this is all moot right now since the api calls don't exist at this point, I just wanted to get my argument out there that there are some good reasons to allow this sort of thing.
  
  Thanks for your help and consideration. I do appreciate it.

  Vista does allow developers to access the individual controls on the audio device (like the mux) control, if you look at the IDeviceTopology

  
  

• F. Gsell

  Thanks, that's a helpful suggestion (although in our case, it would require a substantial rewrite of our control panel, so this might be more of a long-term solution).
  
  Some of the most useful features of our control panel can't be implemented this way, though. We have a "preset" feature where a user can create named sets of all of their audio settings and easily switch between them. Suppose you used your computer for a couple differt things: listening to music on your full surround system, producing a little podcast, and you might listen to music on your wireless headphones once the kids have gone to bed. Each of these situations involves many different audio setting, some standard ones, and some custom to our device. Using our preset feature a user can easily, quickly and reliably change all the necessary settings--without it they've got to do the job manually, or possibly create separate user accounts for each situation.
  
  Under Vista, though, the default recording source and output device (these are very important settings!) can't be a part of a preset.
  
  So, for the lack of a few api methods, we'll have to give our customers a less useful control panel. And, unless we significantly rewrite it, an incomplete one. I'm not saying this to be rude, but I just want to convince whomever makes these decisions to trust us developers not to misuse these api calls. We are going to use them to enhance a user's Vista experience, not ruin it. Really, DeleteFile() is potentially a far more dangerous api than SetDefaultAudioEndpoint() ever could be anyway.
  
  I think we are going to simply have to direct users to the Vista sound control panel to change their default recording/playback devices. Possibly launch it for them. Users will probably perceicve this as "lame" but I don't think we have a choice.
  
  Thanks for your help, Janaka. Is there anyone you can suggest I send my argument about including this api call (and other similar ones) to
  
  Thanks, again.
  John
  
  
  

• xlordt

  Larry Osterman wrote:

  Microsoft DOES provide a mechanism for a new audio device to indicate that it should be the preferred device, this is typically used for USB audio devices.

  Very interesting. Do you have a reference for how this works

  Leo Havmoller.

  
  

• drummstick

  Thanks for the info, Larry.
  
  I think we cross-posted because I didn't see your post when I started my last reponse.
  
  It's true there wasn't previously an api to change the default device, but the OS did not prevent us from setting our device's audio path (under XP, we can control the recording source by setting the value of a Mux control). Under Vista we can set the input line of the mux control all we want, but as soon as someone starts recording, the value is changed (as it should be).
  
  This is all as it should be; the Vista audio model focused on the actual "endpoints" that users interact with is a nice improvement over the old method. We'd just like full access to the user settings that control this model. Remember, we don't want to take control of the user's setting--but rather to give them an alternate, more powerful and more convenient access to those settings.
  
  Anyway, I realize this is all moot right now since the api calls don't exist at this point, I just wanted to get my argument out there that there are some good reasons to allow this sort of thing.
  
  Thanks for your help and consideration. I do appreciate it.

  John

  
  

• Confused4130

  Actually, the WASAPI APIs won't help in building control panel extensions.

  First off, to anwer the original question: We do not and have never provided APIs that allow an application to change the default devices, just like Microsoft has never provided APIs to pin programs to the start menu. This is functionality that is reserved for the user, because of the potential for abuse.

  Microsoft DOES provide a mechanism for a new audio device to indicate that it should be the preferred device, this is typically used for USB audio devices.

  Also, you should contact your MS rep for Vista DDK documentation, that should give you information about how to write an audio control panel extension.

  
  

• arkiboys

  I may be missing something here, but it seems to me that if you are prepared to master the Device Topology API, you can do under Vista exactly what you can do under XP, i.e. you can set Mux and Mute switches etc. for individual devices, but you cannot change the default input and output device. It's annoying that the old mixer API's no longer function though; given that the new Device Topology API is just the old mixer API in disguise, I can see no harm in providing an API call to 'turn on' the full mixer API for Vista-aware applications - it would save people like vtb (and me!) a lot of work.

  I've just spent a few days grappling with the new audio API's and, although audio endpoints look nice on the surface, they are not so nice in practice. I want the user of my application to be able to select which recording device to use without having to resort to the Sounds applet (i.e. I don't want him/her to have to change the default input device just for my benefit). You would think that you might do this as follows:

  IAudioClient *pAudioClient;

  hr = pMyDesiredInputEndpoint->Activate (__uuidof (IAudioClient), ..., (void **) &pAudioClient);

  hr = pAudioClient->Initialize (...

  But no! Initialize just returns AUDCLNT_E_DEVICE_IN_USE for all input endpoints on the adapter except the one currently selected in the Sounds applet. I assume that this is by design, but it is deeply flawed. The call should only fail if another endpoint on the device is actually in active use (in which case I want the call to fail, of course).

  You can use the device topology API's to change the input mux, but then, like the old XP mixer API, you run the risk of sabotaging an application which is already recording from a different endpoint. And worse, you can't find out if another application is 'using' the mux, so it is impossible to write a well-behaved application in this regard.

  In short, it's a can of worms. I would like endpoints (and specifically, input endpoints) to work as follows:

  • if an application attempts to open an input endpoint, it should always succeed unless a different input endpoint on the same device is already open
  • if another input endpoint on the same device is already open, then our open call should fail with 'device busy'
  • Vista should (as necessary) transparently set the mux when an input endpoint is opened and then restore it (to the default set in the Sounds applet) when the endpoint is closed (see bug report!)

  I.e. Vista should manage the input mux and not me. Is this asking too much I think not. If application developers are expected to work with endpoints, then endpoints should work with the developer.

  
  
  

• Fluxtah

  Thanks for the quick reply, Janaka.
  
  I hope the powers that be will reconsider that decision, though, and here's why:
  
  We sell sound cards to consumers, and we give users access to the distinguishing features of our product through a control panel. We feel that it is very important to the user experience that they be able to access and control the full features of our device from one place via a single, consistent user interface.
  
  Without this capability our users will have to partially access and control a device from our control panel, and partially from the Vista control panel.
  
  Is there a recommended method for vendors in our position to handle something like this
  
  Thanks again,
  
  John
  
  
• Programatically setting the default playback device (and recording device)