none
Programatically setting the default playback device (and recording device)

    Question

  • Under Vista is there a way to set the default playback device programatically? I've searched through the APIs but I'm not seeing it. For example, there is a method IMMDeviceEnumerator::GetDefaultAudioEndpoint(), but there is no corresponding IMMDeviceEnumerator::SetDefaultAudioEndpoint().

    Can I do this through the endpoint properties?
    • Moved by The March Hare Thursday, July 09, 2009 2:52 AM not related to Media Foundation (From:Media Foundation Development)
    • Moved by Jundan WuMicrosoft contingent staff Wednesday, November 21, 2012 7:18 PM (From:Off-Topic Posts (Do Not Post Here))
    Tuesday, October 31, 2006 3:02 PM

Answers

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

     

    Tuesday, October 31, 2006 6:11 PM

All replies

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

     

    Tuesday, October 31, 2006 6:11 PM
  • 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
    Tuesday, October 31, 2006 8:16 PM
  • 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

     

    Thursday, November 02, 2006 1:24 AM
  • 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.

     

    Thursday, November 02, 2006 3:08 PM
  • 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

    Thursday, November 02, 2006 3:37 PM
  • 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

    Thursday, November 02, 2006 6:42 PM
  • 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)

    Thursday, November 02, 2006 6:56 PM
  • 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

    Thursday, November 02, 2006 7:01 PM
  • 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.

     

    Thursday, November 02, 2006 7:04 PM
  •  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 Havmøller.

    Monday, December 11, 2006 3:05 PM
  • 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.

    Sunday, December 24, 2006 12:21 PM
  •  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.
    Tuesday, February 06, 2007 5:26 PM
  • 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

    Tuesday, February 06, 2007 5:50 PM
  • I don't think so, but I will check again when I have time.

    Regards,

     

    Tuesday, February 06, 2007 7:10 PM
  • Windows 2000/XP: I also used to mess directly with the registry values, but found that it didnt work as expected on some localized windows version (Polish, i think). I now use DRVM_MAPPER_PREFERRED_SET, which works perfectly on both Windows 2000 and XP, and even updates the control panel sound & audio devices, if it is open. The DRVM_MAPPER_PREFERRED_SET value is missing from the headers, use: #define DRVM_MAPPER_PREFERRED_SET (DRVM_MAPPER+22)

    Windows Vista: The "Microsoft DOES provide a mechanism..." statement refers to the SetupPreferredAudioDevices INF directive. I guess it has some value if you provide your own INF with your device, but it useless for a normal USB audio device that uses the built-in INF. Check the wdma_usb.inf that comes with Vista. You will find that the only device that uses the [USBAudio_NonPreferred.AddReg] section is a "XBOX 360 Headset Device". Every other (USB) audio device will be set to the preferred device. Sigh.

    Unfortunately, DRVM_MAPPER_PREFERRED_SET doesnt work in Vista, and I havent found another solution. But the control panel can do it, so it must be possible. I just havent had the time to step through the control panel code yet.

    Leo Havmøller.

    Wednesday, February 07, 2007 5:19 AM
  • Hi Mitch,

    I just dug out my test program, and you are right - access to the end point is only denied if the Sounds applet is open.  Apologies.

    Mind you, it would be nicer if the Sounds applet could be persuaded to let go of an endpoint that it is merely monitoring.  The current behaviour is very confusing, and hard to explain to users.

    Regards,

    Wednesday, February 07, 2007 6:17 PM
  • Thanks for checking -- it's good to know that it's working as designed.  Your feedback wrt monitoring the endpoints is certainly noted. 

    Thanks.

    Wednesday, February 07, 2007 6:48 PM
  • Can anyone shed some lights on how to solve the problem described by skst? We run into same problem here. Thanks.
    Monday, April 16, 2007 6:35 PM
  •  Janaka Goonasekera - MSFT wrote:

    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.



    Hi there,

    I arrived here after wanting to develop a small app that just lets the user toggle the default playback device using a global hot key, that's it. I know, I'm late to the discussion, but I think given the proliferation of USB audio devices (headsets, mics, etc.), it would be a nice thing to have (sort of like an Alt+Tab-like interface).

    Is there any chance this can be suggested to MSFT so that it can perhaps be implemented directly by them, and where would I be able to make that suggestion?

    Thanks,
    Rizwan
    Wednesday, April 18, 2007 1:52 AM
  • If you read this entire thread, it depends on whom you believe--Janaka Goonasekera or Larry Osterman.

     Janaka Goonasekera wrote:
    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.

     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.

    And as I pointed out earlier, it seems as if both are wrong:

     skst wrote:
    When we connect our USB audio device to a Vista machine, Vista automatically sets it as the default audio device. We want Vista not to change the default device. (From this discussion, I thought Vista's would not 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.

    I think everyone's questions boil down to:

    • Can we set the current audio device in Vista or not? If so, how?
    • Can we tell Vista not to change the default audio device to the one that was just installed? If so, how?
    Wednesday, April 18, 2007 1:26 PM
  • There's no conflict between what Janaka and I said.  There IS no way to programatically change the default device.  End of discussion.

     

    If you are creating your own audio solution, you can indicate (in your .inf file) if you want the audio device to become the new default (this has been in place since Win98).  The Microsoft USB class driver uses this mechanism to make all new USB devices the default device.

     

    There is a QFE for Vista (and XP) in the works that changes the way that the system deals with new devices - with the QFE, USB headsets (and a couple of other types of devices) won't automatically become the new default device when plugged into the machine.

     

    I suspect that the QFE may fix your problem (however it's not yet been published).

     

    Wednesday, April 18, 2007 1:37 PM
  • skst,

    I believe that once you plug in an audio device and Vista switches to it, you can at that point go in to the Control Panel and switch it back. From then on, it will not switch to to the new device. Can anyone else confirm this?


    I think my question is still valid - Can MSFT provide a handy global hot key to cycle through default audio playback devices and set them? Even if it's something obscure like WindowKey + Shift + A. Where can we suggest this sort of feature?
    Wednesday, April 18, 2007 3:58 PM
  • Yes, that's true. However, as has been discussed in this thread, one of the goals of Vista is to not make the user switch their audio devices back to the default. Unfortunately, the built-in wdma_usb.inf forces the user to do just that, and we have to document it (and translate it into 15 languages). It's a real pain. Yes, we can write our own INF to use the default Windows driver, but I don't understand why MS's own INF is constructed to change the user's selected audio device to whatever new device is plugged in.
    Wednesday, April 18, 2007 7:11 PM
  • There is a way to change the default device programmatically, well, sort of..., and it's ugly. But if it's the only way we have, some of you may find it interesting (you may already have thought about it).

    It is possible to start the Sound control panel, find its window and emulate windows events to change the default. The user will of course see the window briefly.

    A simple keydown/keyup event works, I have a custom (read: personal) tool which does that.

    The exercice of determining how to make it fool-proof in finding the applet window or knowing which devices are listed in which order is left to the reader

    No, I don't like this solution, and I would kindly remove it from my tool if another solution would be made available. I would also probably recommend against implementing it anywhere. But sometimes we are not given choice.

    Regards.
    Monday, May 07, 2007 6:21 AM
  • If you're going to go that route, use the MSAA (Active Accessibility) support.

     

    It's far more reliable and more likely to work.

     

    Monday, May 07, 2007 5:10 PM
  • Here you say "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." 

     

    How can this be accomplished?  I've tried using "SetupPreferredAudioDevices" in the INF without success. 

     

    Thanks.

    Tuesday, May 15, 2007 4:02 PM
  • Here you say "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."

     

    How is this accomplished?  I've already tried to add "SetupPreferredAudioDevices" to the INF without success.

     

    Thanks.

    Tuesday, May 15, 2007 8:20 PM
  •  

    Hi,

     

    I know I am just arriving in a nearly-ended discussion, but I am not the only one to meet this problem.

     

    I use Vista Media Center to listen to music, watch videos...

    With XP I had no problem to output the sound to both SPDIF and analog outputs simultaneously.

    No more possible with Vista, too bad...

    Same problem when I want to switch from my HT receiver to a headset : I have to switch manually from one device to another

     

    So, sorry to insist but I wish it would exist a way to switch from one device to another, with a hotkey, or a setDefaultAudioEndpoint API (which could be called by a plugin inside media center).

    The INF file solution only concerns drivers, and what about end users like me ?

     

    I agree that with XP this feature was not present, but you can admit that with XP the sound was broadcasted to all the devices, so this problem did not exist ?

     

    Thanks

    Regards,

     

    Damien Bain-Thouverez (http://damienbt.free.fr)

     

    Thursday, June 21, 2007 2:37 PM
  • Hi. I got here after searching for ways to programmatically change the default audio device in XP, as an end-user. I thought it might help to describe my scenario:

    I play computer games and use VOIP applications at the same time to talk with the people I'm playing with. I want to have the game playing through my computer's speakers, and the VOIP app use my Bluetooth headset. Unfortunately, the headset vanishes as an audio device whenever it is disconnected. When it is reconnected, it becomes the default audio device. Generally this change of audio device causes any game to cease making and sound at all until restarted. Games in general do not allow me to select to output to something other than the default audio device.

    At the moment, if I am playing a game and want to start using VOIP, I have to do this:

    1) Quit the game.
    2) Connect my Bluetooth headset.
    3) (Often this fails and I have to disable and re-enable bluetooth radio before it will work.)
    4) Open control panel.
    5) Open sounds and audio devices.
    6) Set the default playback and recording devices back to the regular ones.
    7) Start up the VOIP app.
    8) Make sure it's set to use the headset (it will forget if I ever start it when the headset is not connected).
    9) Restart the game.

    I hope you will agree that there are about twice as many steps in here as there should be. People seem to be suggesting that there's a way to programmatically change the default device in XP, just not in Vista. It would certainly be good if XP didn't automatically change the default device when the headset connects, though.
    Thursday, July 05, 2007 11:44 PM
  • If this is for MCE, you can use DRVM_MAPPER_PREFERRED_SET. See my posting about this.

    If this is for Vista Ultimate, then it is not possible. Your finding of SetDefaultEndpoint is the closest to a solution yet.

     

    Leo Havmøller.

    Wednesday, November 21, 2007 6:29 AM
  •  

    Vista is a Big step back in  Recording sound control   in Xp you could adjust the different devices in your  Sound card stereo  mixer  and with  also using the Playback  controil you could adjust the sound level of your mic or other devices  you use to  record or to chat with voice online  .with vista if your mixer is  selected  you  and your mic is plugged in  the mic  is on  

     Vista is a big step backwards   thats  is a shame

     

     

      meanimal

    Thursday, February 28, 2008 10:24 PM
  • I have my HDTV connected to my computer with the SPDIF out, which is a separate device from my computer speakers. I want to be able to switch my primary display to the HDTV and my default device to SPDIF with a single shortcut key so a button on a remote control could be programmed to do that. Unfortunately, Windows Media Center (at least the Vista version) uses only the default playback device. When you change the playback device using the Media Center menus, it doesn't just start using the device you select--it actually changes the default device and then uses whichever is the default (not sure why Media Center is allowed to do it programatically). This is a huge pain to go back and forth.

     

    Here is an idea for a solution that might work. Create an emulator device that would sit in your list of playback and recording devices. The emulator could then be set as the default playback device (or default recording device). The emulator would take audio sent to it, then forward this audio to a second or third device (or both simultaneously). The user could configure the emulator as needed. For example, the user could specify that when Media Center is running in the foreground, the audio is to be sent to both the computer speakers and SPDIF. Otherwise, audio is to be sent only to the computer speakers. Or, the user could specify that when a certain hotkey is pressed, the audio automatically toggles between the computer speakers and SPDIF.

     

    This emulator would fulfill the requirements set by Vista (user has complete control of default audio device), provide compatibility with the huge majority of software that just uses only the default device, and allow users (like me) to automate things, which is why computers are useful in the first place. (It still wouldn't solve the problem of the newly inserted USB device becoming the default.)

     

    Although Vista should already have a solution for this problem, I'd pay good money if someone could (or already has) create it. I'm sure others would as well.

     

     

    Tuesday, March 04, 2008 5:44 AM
  •  

    Your emulator idea is just too complicated and maybe not doable.

     

    I have already implemented a beginning of a solution to switch the default audio device from the remote control (by using a configurable button sequence). Of course it does not solve your problem but this is a more flexible solution than going into the setup menu of media center or playing with the mouse under the audio system tray to select the device.

     

    The solution can be applied by installing my plugin Media Control : http://damienbt.free.fr and define a macro with the configuration program.

     

    I defined 2 macros for mine : one to switch audio device to SPDIF, another to switch audio device to analog output and then restart media center after the change so that it is taken into account.

    Each of this macro is called with a button combination : yellow button + 1 for SPDIF, yellow button + 2 for analog

     

    Damien

    Tuesday, March 04, 2008 10:34 AM
  • I have a simpler question that is so close tyo the topic, I figure it's a good place to ask.

     

    Is there a way of programmaticaly FINDING the defualt playback and recording devices on Vista? 

    Not change, just find out which ones are the default(s).

    In XP I could pick them up from HKCU\Software\Microsoft\Multimedia\Sound Mapper, but this does not seem to be the case in Vista.

     

    Thanks!

    Tuesday, March 25, 2008 1:03 PM
  •  

    CoCreateInstance(IMMDeviceEnumerator)

    IMMDeviceEnumerator->GetDefaultAudioEndpoint(eConsole)

     

     

    Tuesday, March 25, 2008 2:13 PM
  • Thanks Larry.

    That was extremely quick! I will try it and let you know.

    Tuesday, March 25, 2008 2:30 PM
  • rech: You really don't want to go there.

     

    This is an internal-only interface that you've reverse engineered, and IS going to change from build-to-build of Windows. 

     

    There is no expectation of API persistance with internal-only interfaces.  Mitch and I have explained this many times.

     

    Out of curiosity, why do you want to be able to change the default audio device?  Why don't you trust your users to make the right decision for themselves?

     

    Tuesday, April 01, 2008 3:29 PM
  • I, for one, would like to easily be able to change the default audio device in one-click on a tray icon, because I need to change it several times a day.

    Several people have two audio devices on their system - for instance, a 5.1 device for speakers with plugs on the rear of their machine, and a AC97 device on the front in which they plug earphones. Switching from one to another programmatically is very useful, instead of having to either unplug or turn off speakers when needed.

    Reaching the audio properties in the control panel is Ok when you have to do it once in a while, but being able to do it in one click is a must.

    So far there is no way I can write an app which can do it reliably, apart of send windows messages to open that window and choose another device automatically, but it's neither efficient nor appealing.


    Tuesday, April 01, 2008 3:44 PM
  • So you're dealing with a legacy machine - modern computers (many (not all unfortunately) vista logo'ed machines) that support HDAudio support jack detection - Windows gets notified when you plug in your headphones in the front and changes the default device for you.

     

    You could use active accessibility to script the control panel if you wanted a documented way of doing this, but there is very intentionally no documented way of doing this.

     

     

    Tuesday, April 01, 2008 3:48 PM
  • Not legacy machines. I'm aware of jack detection. But I don't want it to be automatic, I want to keep everything plugged in, and be able to switch from one to another in one click. I'm not alone in this case, and I'm dealing with people with disabilities who are able to click on an icon but not to plug or unplug headphones.

    Anyway, that's just one of the (multiple) reasons that kept me from upgrading the machines to Vista. Easier to do this in XP.
    Tuesday, April 01, 2008 4:02 PM
  • It seems to me that the real problem with all this is that the windows default playback device is heavily overworked.  Programs should let the user select the output device he/she wants to use (e.g. a handset, for Skype), rather than relying on the default device being (and remaining) what they want.  Microsoft seem to want to hide the user from these details, but as more and more machines have more and more audio devices attached, this approach simply doesn't work.

     

    What is missing from the bigger picture, IMO, is an 'audio device chooser' to select the playback and/or recording device to be used for that application, with a common user interface across all programs.  MS should have provided this long ago, IMO, and are they (and we!) are now sufferring as a result.  What we have now is a mess, and don't get me started on the behaviour of some USB devices.

     

    Just my $.02 worth.  Our own (audio-based) app makes selection of the recording and playback device fairly prominent in the user interface, so being unable to set the defaults does not bother us too much.  It was something of a pain to program though, especially to make it work on both XP and Vista.  Could use the time elsewhere!

    Tuesday, April 01, 2008 4:43 PM
  •  

    Paul, I totally agree with you.  Applications SHOULD have the ability to chose the output device. 

     

    And Microsoft HAS provided APIs to do exactly what you ask, and has since 1991.  There are at least 4 different ways of enumerating the audio devices in a Windows machine:

    waveOutGetNumDevs/waveOutGetDevCaps

    mixerGetNumDevs/<a lot of other mixer APIs>

    DirectSoundEnumerate

    IMMDeviceAPI (Vista only)

     

    All of these work to allow an application the ability to enumerate the audio output devices on the system and select the output device the user wants.

     

    IMHO there's no point in having a common UI control to enable this since it's trivial to wrap these entities into the UI control of your choice (I could see a listview being used or a listbox).

     

    I'm not sure why you'd want to set the default audio device for just the application - most of the rendering APIs in the system allow you to specify which output device you want to use (the big exception to this rule is the WMP OCX).

     

    Tuesday, April 01, 2008 4:52 PM
  • Hi,

     

    Well, it's not too bad under XP (although the mixer API's are fairly heavy going), but under Vista its a bit tricky, because (a) the mixer API's no longer present a true picture of the underlying hardware (rendering them largely useless), and (b) the new Vista IMMDeviceAPI does not provide wave device ID's for use with the waveIn / waveOut functions.  I've sorted it all out now, but it was a pain to do and it took a while to get it right.  If point (b) was attended to, it would be a lot easier for guys like me, with tried and tested code based on waveIn and waveOut, to move our code over to Vista.  And I believe I'm in the majority here.

     

    And I think there *is* a point in providing a common UI for this.  For example, when setting the playback device, our app provides a 'Test' button which plays a bit of Beethoven's fifth (what else?) to let the user see if things are working, and on the input side we provide a level meter, plus the option to play the input signal back through the speakers, for the same reason.  Add this to the XP vs Vista API shindig and it all adds up to a non-trivial job to do it properly, which is why I feel that MS have passed the buck.  Anyway, the proof is in the pudding - look at the mess we are in with all this.  And is it true, as mentioned elsewhere in this thread, that WMP on Vista will only play through the default playback device?  If so, shame on you!

    Tuesday, April 01, 2008 6:37 PM
  • Paul, actually the mixer and wave APIs DO provide a true picture of the underlying audio subsystem.  The mixer APIs don't reflect the hardware by default, but they DO reflect the devices you can use for rendering or capturing.

     

    You're right that mmdevapi doesn't provide the mixer or wave device, but you CAN figure out the mapping - this page describes how to do it.

     

    So what would a common control for selecting an audio device look like?  You're describing something very different from what is typically available in a common control.

     

    And the WMP playing on the default playback device in Vista was a mistake, plain and simple.  Essentially lines got crossed between the sound team and the media player team and by the time we figured it out, we were in UI lockdown and couldn't make the change.

     

     

    Tuesday, April 01, 2008 6:46 PM
  •  Larry Osterman wrote:

    Paul, actually the mixer and wave APIs DO provide a true picture of the underlying audio subsystem.  The mixer APIs don't reflect the hardware by default, but they DO reflect the devices you can use for rendering or capturing.

     

    PaulS> Yes, I remember vaguely.  It's been a while and I can't remember exactly why I couldn't use them but the fact that they concatenate the audio line and device name and then subsequently truncate them was certainly one.

     

    You're right that mmdevapi doesn't provide the mixer or wave device, but you CAN figure out the mapping - this page describes how to do it.

     

    PaulS> Wish I'd known that sooner!  I did something similar in fact, matching strings and suchlike, but I rolled my own.

     

    So what would a common control for selecting an audio device look like?  You're describing something very different from what is typically available in a common control.

     

    PaulS> Not a common control, as I see it, but a pair of common dialogs (one for input, one for output), a bit like choosing a printer.  FWIW, our 'input device chooser' looks like this on XP:

     

    http://www.alpinesoft.co.uk/VinylStudio/images/lc.gif

     

    On Vista, there's just a single dropdown (entitled 'input source').

     

    And the WMP playing on the default playback device in Vista was a mistake, plain and simple.  Essentially lines got crossed between the sound team and the media player team and by the time we figured it out, we were in UI lockdown and couldn't make the change.

     

    PaulS> Well, I don't want to be contentions, and this means little to me personally, but this sounds a bit thin to me.  Surely the WMP team had the IMMDevice API available well in time and knew (from WMP 9) that they should make the playback device selectable.

     

     

    I think I've beaten the drum long enough about this, but one thing that is in danger of getting lost in the fog is that the Vista IMMDevice API is a *huge* improvement on the XP mixer API, which was not very pleasant to work with, so kudos there, guys.

    Tuesday, April 01, 2008 8:19 PM
  •  

    The WMP default device playback was a mistake, plain and simple.  The WMP team made a change based on functionality that they thought that the audio team was delivering, but they didn't tell the audio team that they'd taken a dependency on the new functionality.  Fairly late in the game (for unrelated reasons), the audio team decided to back out that functionality (you can see the vestiges of it in the IMMDeviceEnumerator::GetDefaultAudioEndpoint API).  By the time that the WMP team realized that the audio team had backed out the functionality, it was too late to put the XP functionality back (the audio team hadn't realized that the WMP team had taken the dependency on our new feature).

     

    It sucks, and it's highly likely that this oversight will be corrected in a future version of Windows.

     

    Tuesday, April 01, 2008 8:28 PM
  • Larry Osterman:
           you said that not api and other way to change the default audio for developer,but why Power mixer can change the default audio.
           I have develop a appliction for skype phone ,skype request the not change  os's default audio. but OS let my phone set the default audio device of OS,so,i will look up ways to change the default audio device.

    Wednesday, April 02, 2008 12:39 AM
  • Larry Osterman:
           you said that not api and other way to change the default audio for developer,but why Power mixer can change the default audio.
           I have develop a appliction for skype phone ,skype request the not change  os's default audio. but OS let my phone set the default audio device of OS,so,i will look up ways to change the default audio device.

    Wednesday, April 02, 2008 1:12 AM
  • Larry Osterman:
           you said that not api and other way to change the default audio for developer,but why Power mixer can change the default audio.
           I have develop a appliction for skype phone ,skype request the not change  os's default audio. but OS let my phone set the default audio device of OS,so,i will look up ways to change the default audio device.

    Wednesday, April 02, 2008 4:59 AM
  •  

    Ah, I see Larry.  You are referring to device roles, I take it.  Thank you for drawing them to my attention.  I have to confess that I had ignored these, but I can now see that they are a good solution to the 'there can only one be default device' problem - or would be, if implemented!  I will in any case change my app to use eMultiMedia - nothing to lose there.

     

    One thing I happen to know though, is that many (probably all) USB audio devices currently know nothing about device roles, so the days of plugging in a skype phone (or indeed some input-only devices!) and finding that your speakers have stopped working is likely to remain with us for a long time yet.

     

    Larry, I appreciate the time you put into posting to this (and no doubt many other) threads.  I (and no doubt many other small developers) often feel a bit like a voice in the wilderness.

    Wednesday, April 02, 2008 8:47 AM
  •  Larry Osterman:

             I write a appliction for skype phone .my skype phone is a usb audio device.when it been plug to pc that os let it been default audio device.but skype ruquest not change os 's default audio device.so i want to change default audio to before.but you said not api can do.So i want to do this?or not  let os change my skype phone not been default device.but i do not know how to do it.and i know a appliction can change default audio device(Power mixer),and how to do this?

     

    thanks!

    Wednesday, April 02, 2008 3:15 PM
  •  

    Hi, Larry,

     

    I've been follow this forum thread for the last weeks and find it very relevant for ny app needs.

    I want my app to set an endpoint device as default on vista (programatically of cource).

    Earlier in this long session u & wrote:

    << There's no conflict between what Janaka and I said.  There IS no way to programatically change the default device.  End of discussion. >>

    But then in the last message u wrote:

    << All of these work to allow an application the ability to enumerate the audio output devices on the system and select the output device the user wants. >> (including IMMDeviceAPI as deduced)

     

    I am getting a little confused, it seems like a contradiction to me.

     

    In addition, the IMMDeviceAPI provides only the IMMDeviceEnumerator::GetDefaultAudioEndpoint( ) and not the corresponding Set function (which select the audio device as default)

     

    I'll apritiate your explanation.

     

    Thanks.

    Tuesday, April 08, 2008 3:37 PM
  • There is nothing that prevents an application from showing the user a list of outputs and sending the audio to that output - FOR THAT APPLICATION.

     

    We don't allow an application to change the default for all applications.

     

    Tuesday, April 08, 2008 4:34 PM
  • Thanks for the quick response.

     

    Although, I am curious about one more thing.

     

    When I use the sample code in this msdn link:  http://msdn2.microsoft.com/en-us/library/ms678713(VS.85).aspx (the 2nd sample), I can't reach the MUX during traversing the data path. Second thing is, if Its possible to do that, why can't I use the  IAudioInputSelector:Tongue TiedetSelection( ) function to select an input of the the required endpoint device. Or in other words, if setting device as default is not allowed, what does the function IAudioInputSelector:Tongue TiedetSelection( ) used for?

     

    Thanks,

    Moti.

     

    Tuesday, April 08, 2008 5:20 PM
  •  

    Moti,

      Do you know if your audio solution actually has a MUX control?  Many don't, especially on modern audio solutions.  You shouldn't have to do anything with the MUX in Vista, the Vista audio stack will automatically flip the Mux when an audio stream starts.

     

    The IAudioInputSelector:Tongue TiedetSelection method simply allows an application to flip a mux control.  It's primary use is for the times when an application wants to totally bypass the Vista audio engine (if they're using DirectKS or ASIO, for example).

     

    Tuesday, April 08, 2008 7:44 PM
  • Thanks, Larry.

     

    If I may, another issue I'm dealing with is controlling the "Windows Sounds" line under Vista. Under Xp it was possible to reach this volume control the same way as for all other volume controls, but in Vista I can't find any suitable API for this in the Audio core documentation.

     

    I will be gratfull if u could give me a hint...

     

    Thanks.

     

    Wednesday, April 09, 2008 8:34 AM
  •  

    Moti: I'm confused.  On XP, there was no "windows sounds" slider, that's new functionality that was added for Vista.

     

    You had no way of controlling the volume of system sounds relative to the volume of other applications.

     

    Maybe you're thinking of the Mac?  It's my understanding that OSX allows you to change the volume of the system sounds.

     

    Wednesday, April 09, 2008 3:35 PM
  • Maybe he means the mixer line called 'Wave' on many soundcards (including mine, a Realtek AC97 Audio).

    Wednesday, April 09, 2008 3:44 PM
  • That's possible (that he meant the "Wave" slider).  We quite intentionally removed that from Vista because it was a significant PSS headache for us and our OEMs.  Essentially the wave slider and the master volume slider functioned as two volume controls that were in series, and one of them (the wave slider) was buried in the UI.  So we got calls from customers complaining that they couldn't control the volume on their machines - the machine was too quiet even though the sndvol slider was at the top.  The root cause was invariably because they'd run some random application that set the wave slider to some low value, which in turn lowered the audio for the entire machine.

     

    For Vista, it was critically important that we take the opportunity to fix this, so we replaced the global volume with per-application volume.

     

    Wednesday, April 09, 2008 4:45 PM
  • Hi, Sorry for the delayed reply.

     

    Truely I meant the "Wave" line in Xp OS. I thought that the "Windows Sounds" slider in Vista might have replace the Xp "Wave" Slider but now I realize I should control my application slider.

     

    Thanks a lot.

     

    Thursday, April 10, 2008 11:52 AM
  • hi,rtxleh

    DRVM_MAPPER_PREFERRED_SET didn't work too. why?

     

    #define DRVM_MAPPER 0x2000
    #define DRVM_MAPPER_PREFERRED_GET (DRVM_MAPPER+21)
    #define DRVM_MAPPER_PREFERRED_SET (DRVM_MAPPER+22)

     

     mr = waveOutMessage((HWAVEOUT)WAVE_MAPPER,DRVM_MAPPER_PREFERRED_SET,1,0);
     if (mr != MMSYSERR_NOERROR) {
      ShowMMSyserr(mr);
     }

     rtxleh wrote:

    Windows 2000/XP: I also used to mess directly with the registry values, but found that it didnt work as expected on some localized windows version (Polish, i think). I now use DRVM_MAPPER_PREFERRED_SET, which works perfectly on both Windows 2000 and XP, and even updates the control panel sound & audio devices, if it is open. The DRVM_MAPPER_PREFERRED_SET value is missing from the headers, use: #define DRVM_MAPPER_PREFERRED_SET (DRVM_MAPPER+22)

    Friday, April 25, 2008 6:38 AM
  •  Janaka Goonasekera - MSFT wrote:

    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.

     



    I'm writing an application that has a legitimate use and need for changing the default audio device, because we want to redirect audio from *all* applications to a particular audio device.

    I've been following this thread and tracking this on the Internet for a while, hoping for a resolution, because there are dozens of developers out there who have this need and MS has essentially turned their back on them for this.

    I have two questions for the MS folks here.

    (1)  *Most* applications have no reason for changing the default audio device, I'll agree with that.  But, do you honestly believe there are *no* applications which have a legitimate and reasonable need to do this?

    (2)  When our users complain about audio switching issues, who at Microsoft do we redirect their support calls to?
    Wednesday, April 30, 2008 6:20 PM
  • That is liek saying if OPEC expects the US to work with them then they should work with the US

     Good luck...:-)

     

    Monday, May 26, 2008 6:09 AM
  • Hi guys... hope ur still lookin here somtimes... im running Xp pro sp2 (was on vista but it fails lol)

    I dont really care about a program 2 help me change default audio devices... i just wanna b able 2 stop it fron auto changing when i turn on my bluetooth headset... if any1 knows anything... please let me know!!!

    xyzbob@live.com.au i thank u in advance for any assistance Smile
    Saturday, July 12, 2008 10:39 AM
  •  

    Larry (or anyone who feels they can help),

     

    I've been trying for a couple of months to find a solution to our problem and finally found this thread.  We are a small game company that sells a product with a USB microphone.  The USB microphone is manufactured with a USB headset chip, therefore we need to keep WIndows (2000,XP,Vista) from changing the default audio device (both input/output) when installing the microphone (otherwise all sound is dead until the user manually changes the audio output device back).  From what I read in these posts, that much should be possible.  At this point, we don't have the time or the knowledge to make this happen so I need to find someone who we can hire to make this work for us.  It sounds like all we need is an inf file/installer written but am aware it could be more complex.

     

    Anyhow, can you (or again, anyone who feels they can do this) please contact me asap and let me know whether you can help us and what it would cost?

     

    Thank you!

     

    Curtis

    cratica@austin.rr.com

     

    Monday, July 28, 2008 4:21 PM
  • Hi Curtis,

    Like you, we're struggling with this kind of thing at my company.

    You can't prevent the switch when the audio device shows up - but, you can make the audio device never show up.  If your users are running your software, you can programmatically disable the device using SetupDiSetClassInstallParams and SetupDiChangeState.  The device will show up as disabled in Device Manager, and won't show up at all as an audio device / endpoint (so, it won't autoswitch, because the audio device never shows up).

    It's an ugly solution, but it's better than nothing.
    Monday, August 04, 2008 5:06 PM
  • Hello all,

     

    I stumbled across a presentation from AMP summit:

    http://ampalliance.org/files/folders/summit_decks/entry77.aspx

     

    Page 13 says:

    New code (Vista SP1 and XP QFE) will prevent devices from becoming preferred audio devices when plugged in to the PC if they have the correct terminal type:
    0x306 - Communication speaker
    Section 2.4 – Bi-Directional Terminal Types
    Section 2.5 – Telephony Terminal Types

     

    So it should be possible to avoid becoming the default audio device by staying away from the Speaker and Microphone terminal types.

    Wednesday, October 22, 2008 4:32 AM
  • I use a notebook with HDMI out.  I regularly plug it in to my Home Theatre setup via the HDMI cable and regularly have to toggle my default device between the inbuilt speakers and the HDMI.  So I have to open up the Sound Devices control panel, click the device, click set as default, close the control panel.  I was hoping to write a nice little app that would detect the HDMI was being used and automatically change the audio to use it, but now that's not possible. 

    I guess I shouldn't be surprised, but if you're not going to provide an API for it then how about improving the experience for the end user by providing options to auto switch!


    Thursday, October 23, 2008 6:39 AM
  • Try running this code in a process running under the SYSTEM account.  Failing that, it should not be hard to work out which user account the audio service is running under.

     

    I agree that MS should expose this API.  It is clear that there is a desirable and legitimate use for it.  If plugging in any old USB audio device can change the default playback device, then programs should be able to do it too.  As ghosert says, Windows has been successful in large part because it provides such a wide range of API's.  Don't change a winning formula!

    Sunday, October 26, 2008 10:43 AM
  • What monitor tool are you using ghosert?

    Wednesday, October 29, 2008 8:18 AM
  •  ghosert wrote:

    albain:

     

    You may be going a wrong path. I know there is a third-party software implements this function with unpublic COM interface & method.

     

    When I track it by using monitor tool, I find it is using the clsid comes from audioses.dll, and as per what other's finding here, below is the interface and method list.




    Sorry, you're right, I did this a while ago. I confirm that this is in audioses.dll that is used by the audio service.
    And the registry keys  : don't remember the path either, I just remember that the selection is based on a timestamp which is updated when you select another default audio endpoint.

    those registry keys are read-only for user, and write access is delivered to the audio service user.

    I have tried to change those rights and invoke the setDefaultAudioEndpoint method and it worked, but I don't like this solution : I don't want to develop an application that say to the user "please go to the registry and change those rights".

    Also, I think (but I am not sure) that the audio panel is a process that belongs to the audio service so this is useless to investigate on the communication between the panel and the audio service.

    So, as last resort, I developed (inside my plugin Media Control http://damienbt.free.fr) a solution which is far from perfect but that works, by using automation. I launch the panel, scan all the devices listed on the first tab, and set the one wanted.

    Wednesday, October 29, 2008 9:34 AM
  • duanjingying2007,

     

    The spam will NOT be tolerated. This is an abuse of the forum rules.

     

    Thursday, October 30, 2008 1:38 PM
  •  

    Ģ®€ğ§QĻ,

    Can we remove this guy's rubbish from the thread?  It's long enough as it is!

     

    Thx.

    Thursday, October 30, 2008 1:41 PM
  •  Paul Sanders wrote:

     

    Can we remove this guy's rubbish from the thread?  It's long enough as it is!

     

    This has been done. Let us know if it continues. I believe a ban request has been placed.

    Thursday, October 30, 2008 1:42 PM
  • Thank you.  Will do.

     

    Thursday, October 30, 2008 1:43 PM
  • What about the cases where users want to write applications to do the settings for them. Take my case as an example: I have speakers and a Motorla DC800 (bluetooth device to receive audio and play it through an amp). I use the speakers when I'm at the machine and the DC800 when I want to play it through the stereo upstairs. I'd like to write an application that uses a supported API to switch between them. Going through control panel for things like this just silly.

     

    Are you saying there's no API with which I can do this?

    --

    thanks,

    Karl

     

    Sunday, November 02, 2008 1:00 AM
  • Come on MS.  It's pretty obvious from this thread that this is something more and more people using notebooks as multimedia machines/HTPCs are going to want.  You sell plenty of notebooks with Vista Home Premium/Ultimate I'm sure (I own one).  So how about enabling this via an API and requiring it to be run as an Administrator.  That way at least the user will have to give whatever application admin privilidges via UAC for it to do  the switching.

    It's just plain stupid that I can have my display auto switch and not my audio!!

    At the very least allow profiles that can auto switch or at least be able to switched via the command line or a shortcut icon!

    PS In case it helps anyone else I've ended up using AutoHotkey to automate this.  The script I'm using can be found on pastebin.
    Sunday, November 02, 2008 7:08 AM
  •  Paul Sanders wrote:

    What monitor tool are you using ghosert?

     

    I'm sorry that I have no chance to answer your question ASAP, but I don't kow why the "Alert me" function in this forum fail to work for me.

     

    I'm using a montior called "TracePlus Win32".

     

     

     

    Sunday, November 02, 2008 7:39 AM
  • I want to set the default audio device because I hope to offer the user a chance to select a different device when he/she is using my application.

     

    But it seems for now it's not a problem, even if the device is not set default, I can also use it as a device to play/record, no matter it is default one.

     

    But the new problem here is that waveInGetNumDevs api can not return disabled device and also there is no way to enable a disabled device(another unpublic COM& INTERFACE call). So still, I have to ask the user to go to control panel to enable the disabled device by manually.

     

    Can somebody here solve my problem? I know simulate the user action programmatically is a way, but it's complex to enable device.

    Sunday, November 02, 2008 8:44 AM
  • You mean you are allowing the user to select a device within your app (without changing the default)?  That's what I do and I think it's the right way to do it.  The problem seems to be that not all apps allow this.  MS don't make it easy in Vista mind you - there's no 'official' way to map between an IMMDevice and a waveIn / waveOut device ID.

     

    I don't know of any API to enable a disabled device I'm afraid.  As you say, another thing MS have decided to hide from us, pointless though that seems.

    Sunday, November 02, 2008 10:34 AM
  •  Paul Sanders wrote:

    You mean you are allowing the user to select a device within your app (without changing the default)?  That's what I do and I think it's the right way to do it.  The problem seems to be that not all apps allow this.  MS don't make it easy in Vista mind you - there's no 'official' way to map between an IMMDevice and a waveIn / waveOut device ID.

     

    I don't know of any API to enable a disabled device I'm afraid.  As you say, another thing MS have decided to hide from us, pointless though that seems.

     

     

    Hi Paul:

     

    Well, There is an offcial way I found. Have you solved this problem? I think I'v solved it, let me know or contact me by my email address in profile if you need solution.

     

    Thus, at least in my own application, I can let user decide which device to use, but because I fail to change it as default, I can't control other application to use the same device. But this is not a problem.

     

    The only problem is that even if I can list a disabled device by new core audio api. But still there is no way to enable and use it. I will still take my efforts on this.

    Sunday, November 02, 2008 1:48 PM
  •  albain wrote:
     ghosert wrote:

    albain:

     

    You may be going a wrong path. I know there is a third-party software implements this function with unpublic COM interface & method.

     

    When I track it by using monitor tool, I find it is using the clsid comes from audioses.dll, and as per what other's finding here, below is the interface and method list.




    Sorry, you're right, I did this a while ago. I confirm that this is in audioses.dll that is used by the audio service.
    And the registry keys  : don't remember the path either, I just remember that the selection is based on a timestamp which is updated when you select another default audio endpoint.

    those registry keys are read-only for user, and write access is delivered to the audio service user.

    I have tried to change those rights and invoke the setDefaultAudioEndpoint method and it worked, but I don't like this solution : I don't want to develop an application that say to the user "please go to the registry and change those rights".

    Also, I think (but I am not sure) that the audio panel is a process that belongs to the audio service so this is useless to investigate on the communication between the panel and the audio service.

    So, as last resort, I developed (inside my plugin Media Control http://damienbt.free.fr) a solution which is far from perfect but that works, by using automation. I launch the panel, scan all the devices listed on the first tab, and set the one wanted.

     

     

    Hi, it seems you have done something successfully, I like your first solution, can you share some more details here?

    If you can send me the code, that will be appreciated.
    Sunday, November 02, 2008 2:12 PM
  •  ghosert wrote:

    Well, There is an official way [to map an IMMDevice to WAVE device ID] I found. Have you solved this problem? I think I've solved it, let me know or contact me by my email address in profile if you need solution.

     

    Yes, you're right, sorry, I forgot about that.  In fact Larry Osterman was kind enough to point this out in an earlier post in this thread.  Here's the link again, as I happen to have it on my clipboard:

     

    http://msdn.microsoft.com/en-us/library/aa363227(VS.85).aspx

     

    I actually do the mapping in a different, 'home-grown' way, because when I wrote the code I did not know about this.  I should probably change it, future-proof myself.  Other than that, I can do everything that I personally want to do.

     

    Good luck with those disabled devices.  Presumably you are still trying to trace what the Sound applet does.  Must be hard work, especially if it is handing the work off to the audio service.  Or is the entire UI handled by the audio service?  That would make the job a lot easier.

    Sunday, November 02, 2008 5:41 PM
  •  albain wrote:
     ghosert wrote:

    albain:

     

    You may be going a wrong path. I know there is a third-party software implements this function with unpublic COM interface & method.

     

    When I track it by using monitor tool, I find it is using the clsid comes from audioses.dll, and as per what other's finding here, below is the interface and method list.




    Sorry, you're right, I did this a while ago. I confirm that this is in audioses.dll that is used by the audio service.
    And the registry keys  : don't remember the path either, I just remember that the selection is based on a timestamp which is updated when you select another default audio endpoint.

    those registry keys are read-only for user, and write access is delivered to the audio service user.

    I have tried to change those rights and invoke the setDefaultAudioEndpoint method and it worked, but I don't like this solution : I don't want to develop an application that say to the user "please go to the registry and change those rights".

    Also, I think (but I am not sure) that the audio panel is a process that belongs to the audio service so this is useless to investigate on the communication between the panel and the audio service.

    So, as last resort, I developed (inside my plugin Media Control http://damienbt.free.fr) a solution which is far from perfect but that works, by using automation. I launch the panel, scan all the devices listed on the first tab, and set the one wanted.

     

     

    I noticed that not only you can find the interface/method name for an unpublic COM, but also you find parameter list for them. Would you mind tell me how to get them? what's the right way or tool I can use?

    Monday, November 03, 2008 8:45 AM
  • I used a disassembler (IDA pro). Of course I did this privately because this is not legal.


    Sorry, I dropped the code since (because of the registry issue)
    Monday, November 03, 2008 8:55 AM
  •  albain wrote:
    I used a disassembler (IDA pro). Of course I did this privately because this is not legal.


    Sorry, I dropped the code since (because of the registry issue)

     

    Thanks for your informations. At least I know the way to take the efforts.

     

    I plan to public the findings if possible in the future, but as you said it is illegal? I know people win the lawsuit that Microsoft hide the APIs for its own app to beat the third party manufactory.

    Monday, November 03, 2008 11:53 AM
  • Hi guys here.

     

    I'm glad to announce that after couple of weeks' efforts, this mission has been done.

     

    For now I can list all the audio devices, no matter it is disabled/enabled device.

    And I can also enable or disable an audio device.

    For the enabled device, it definitely can be set it as default device without any issue. Albain, you mentioned that there is a registry issue, but I can't reproduce it on my machine, did you operate it with an administrator ?

     

    Well, I do this privately as what Albain said: will public the API be illegal ?

    Tuesday, November 04, 2008 1:49 AM
  •  

    Congratulations ghosert.  You are one smart cookie.  I don't personally need this functionality currently but I have made a note of your successful efforts.

     

    If you do decide to publish, I very much doubt if Microsoft would ever take any action against you.  H ell, Matt Pietrek (and many others) have written entire books based on disassembling Windows and nobody ever bothers them.  In the end, MS usually gain more than they lose from this kind of thing as developers can produce better products as a result.

    Tuesday, November 04, 2008 9:25 AM
  • I want to make sure that readers are aware that this type of code will surely break with future updates and releases of the OS. The impact of software failure in this regard might be minimal for private use of such software, but if you are considering using such a technique in code that will have wider distribution it is important to know that it will break in the future.

     

    In reading through the history of this post, I think you've all done a great job in highlighting the challenge of managing a machine with multiple audio devices and multiple applications attempting to use those devices for different purposes. That challenge was one of the driving decisions behind leaving control of the default device to the user and not opening that up for programmatic control. The current paradigm is one in which the application itself is given a rich set of API's to allow it to select the device it wants to send audio to as well as provide the necessary UI to the user so that their feedback into this selection process can be obtained. One of the choices those applications have is to use the default device, and based on current OS design, the choice of the default device is best left to the user.

     

    With that said, we do so see the need for the OS to make better decisions on how to manage machines with multiple audio devices and based on the scenarios I've seen discussed in this thread I think our internal thinking on this subject is on track. I look forward to being able to share with you advancements we are making in this regard. I hope many of you are planning on attending WinHEC, where you will be able to get a first-hand look at the work we’ve been doing in the audio space.

     

    Richard Fricks

    Program Manager, Windows Audio

     

    Wednesday, November 05, 2008 2:22 AM
  • Windows Audio, Program Manager. Cool.

     

    Finally, I have a chance to talk with you here.

     

    I totally agree your solution about selecting a device in the application instead of setting it as default for the usage purpose. I originally planned to follow this rule. But later I fail to do this because I found I have no permission to enable a disabled device as well, and there is no signal to indicate that which type of device will be set to disabled/enabled by default after installing Vista. Here I can't assume every user know how to list and browse the disabled device and make it enabled in the control pannel correctly. Thus, the problem is here: if my application want to select a device which has been disabled already by Vista, there is no way except reversing engineering and reversing engineering make setting the default device possible as well(Although this is not necessary as what you mentioned above.)

     

    So for the future, If your team can solve the senario I metioned and balance the limitation of the programmer's power and users' right, that will be great. And then I believe people don't have to do RE any more.

     

    Thanks for your explanation and taking your time.

    Wednesday, November 05, 2008 5:07 AM
  • > the choice of the default device is best left to the user

     

    That is not incommensurate with providing an API to do it.  Users use programs and the OS can (and does) make the wrong decision as to when to change the default audio device.  Specifically, if you plug in a Skype phone, Vista sets the default audio output device to the phone itself.  Boom!  My speakers have stopped working.  Case in point.  And there is an obvious market for a little utility that sits in the Notification area and provides a quick and easy way to change the default output device.

     

    Please stop being so precious about this and give us what we want.

    Wednesday, November 05, 2008 8:28 AM
  • Larry,

    I have read through this entire thread and even though it is quite long I am not sure I have seen an answer to this question.  Simply this:  Is there a way, programtically or not, to stop Vista from changing the default audio device to a bluetooth headset once it connects?

     

    Sorry if I somehow missed this earlier.  We don't want to set the default playback device, we just want to stop it from getting changed in the first place.

     

    Monday, November 10, 2008 12:41 AM
  • Edward: On first connect or after the device is paired?

     

    On first connect, you need to modify the SetupPreferredAudioDevice field in the INF file for the device - the vendor for the device has apparently decided that the device should become the default device.

     

    Afterwards, all you need to do is to set the default device to some other device on the machine and the BT device shouldn't become the default device when it arrives.

     

     

    Monday, November 10, 2008 7:03 AM
  • Cratica,

    I struggled for a long time with this and have finally found a solution.  We, much like you, produce a product that uses Bluetooth headsets, but only the microphone part as well.  We need to use the microphone of the Bluetooth headsets, but do not want to change the default output device (usually PC Speakers).  We actually employ two different approaches, one for XP, one for Vista. 

     

    With XP we store the default device name before the headset connects.  After connecting we set it back to the original default wave out device with

     

    lngReturn = waveOutMessageSet( WAVE_MAPPER, DRVM_MAPPER_PREFERRED_SET, lngDevice, 0)

     

    With Vista is actually turns out that all you need to do is simply disable the Bluetooth Ouput Device in the control panel once the headset is connected and this accomplishes the same thing.  In the end, after the headset is connected, the default mic is the BT headset and the default Ouput device remains what it was before the headset connected.

     

     

     

     

    Monday, November 10, 2008 6:03 PM
  • > With Vista is actually turns out that all you need to do is simply disable the Bluetooth Ouput Device in the control panel once the headset is connected and this accomplishes the same thing.  In the end, after the headset is connected, the default mic is the BT headset and the default Ouput device remains what it was before the headset connected.

     

    How do you do this programatically?  Or do you expect the user to do it?

    Monday, November 10, 2008 6:27 PM
  •  

    The choice of default audio device is reserved for the user - it's their computer, in general, they get to decide which device is the default device.

     

    For Windows < Windows 7, an IHV/OEM can choose to say "I would like my device to be the default device" overriding the user choice, that's to accomidate the "I just plugged in my USB speakers, why isn't my sound coming out from them?" problem.

     

    But other than that one scenario, the choice of default output device is reserved for the user, and has been since essentially forever.  There has never been a documented mechanism to set the default output device in Windows.

     

    For Windows 7, there have been changes made to reduce the impact of this issue.  See my PDC talk (PC13) for more details.

     

    Monday, November 10, 2008 6:35 PM
  • Larry,

    Thanks for being so responsive. Looks like modifying the .inf files will not be necessary. We already had a solution for XP and now I believe I see the end in sight to solve our application requirements in Vista. Two things would help us speed our development.

     

     

    1) a .Net example of how to properly determine the default input device name in Vista (necessary to determine when the headset is connected).

     

     

    2) a Vista compatible .Net example of how to programatically disable the Bluetooth Playback device once the headset has connected.

     

     

    This would be of great help to us and aparently would help out Paul above too.

    Monday, November 10, 2008 7:59 PM
  • Hi Edward.

     

    Larry was telling you "There has never been a documented mechanism to set the default output device in Windows."

     

    That means you don't have any way to set the default output device or enable/disable a audio device by using offical/public windows API.

     

    And .NET? That's a high level programming language. It's not easy or possible to use it for the low level programming such as control the audio device. In the most cases, if you really want to use .NET, you have to wrapped the existing Windows API by yourself unless you are so lucky that you find an example which has been written on Internet.

     

    Please use C/C++ directly to invoking .NET uncovered public Windows API

     

    Please use assemble language to invoking the hidden Windows API

     

    That means you still have a long way to go if you have only .NET knowledge.

    Wednesday, November 12, 2008 5:37 AM
  •  Larry Osterman [MSFT] wrote:

    Edward: On first connect or after the device is paired?

     

    On first connect, you need to modify the SetupPreferredAudioDevice field in the INF file for the device - the vendor for the device has apparently decided that the device should become the default device.

     

    Afterwards, all you need to do is to set the default device to some other device on the machine and the BT device shouldn't become the default device when it arrives.

     

     

     

    Larry,

     

    We have the same problem. We manufacture a USB audio device that enumerates itself as a generic usb audio device. Therefore we don't have an INF file to change.

    I've been reading this whole thread, and it seems that this is really the critical part of the discussion. Even before vista, our application managed to select the specific device to play, instead of relying on the default playback device. And I agree that *most* applications should specify which device they play/record from.

     

    The real problem we find is when we sell our product to large companies and as soon as they start plugging our device, the users call the IT guys that call our tech support... and sometimes that even breaks the deal... too much work for the IT guys.

     

    After reading some tips around here, I decided to add the

    HKR,,SetupPreferredAudioDevices,3,01,00,00,00

    to the wdma_usb.inf, but for my surprise, it was already there... so I removed it, but it didn't work. Our device keeps enumerating as the default playback device. I even created a new section on that INF called [USBAudio_NonPreferred.AddReg] (somewhere I saw that XBOX 360 used something like that and it wouldn't turn itself as the default audio device)... no worky as well.

     

    I also found, downloaded and run a package from MS that promised to fix that on Vista

    http://support.microsoft.com/kb/936004

    But when I try to run, it says that "The update does not apply to your system"...

     

     

    So could you or somebody else guide me on how to prevent windows (we are more worried with XP right now, as we have one IT guy holding a 500 units order because of this issue) to set the recently plugged usb audio device as the default one?

     

    Cheers!

    Wednesday, November 26, 2008 9:31 PM
  • Hey all,

    Hate to raise the dead, but there are a few nice leads in this thread, yet unanswered.
    My situation like others, "I am using vista home premium"

    HDMI---AVReciever/Theater using "MS Media Center"
    SPDIF--Direct to pre-amp  using "WinAmp,(SinglePlayerGames)"
    Speaker/Mic--Headset Using "Voip,MultiPlayerGames"

    External Media I can deal with personally. "Ipod,flashdrives,cds"

    I am just tired of making a system default, just because software companies don't have audio preferences.
    Would be nice to have it so I can assign devices to applications.

    Hope someone has an idea.



    Tuesday, January 20, 2009 2:03 AM
  •  Eticus wrote:


    It would be nice to have it so I can assign devices to applications.

     

    Yes it would, wouldn't it?  Something to consider for Windows 7 Larry?  It seems to me that it would be easier to build a comprehensible UI for this than for device roles.

    Tuesday, January 20, 2009 9:31 AM
  • Lila,

     

    Comment out the offending lines.  They are not doing anything important.

    Saturday, January 24, 2009 9:59 PM
  • Larry,

    This was posted to the WDMAUDIODEV freelist but I found this post and thought it would be appropriate to summarize and hopefully get a response here that others can see.

    Our software packages use a method similar to Paul Sanders (sets the default audio device using "macros") because there is no way to change the default audio device.  Our program allows users to have multiple soundcards in their computer that have speakers hooked up to them in different locations (speakers in parents room, speakers in kids rooms, all hooked up to their own soundcard) so each room can listen to something different.  Some of the setups include haunted houses.  We use multiple instances of the Windows Media Player SDK for each soundcard/room.  You stated that the WMP SDK is an exception to the rule in providing the ability to specify the required output device.  This is where are problems lies with Windows 7.  We watched your interview where you talked about "Stream Switching".  In it you said that the audio streams shouldn't be switched to the default device if the software that is playing the audio was set to output to a specific device which the WMP SDK does not provide this needed functionality.  Because we rely on the default audio device that is set when a file is played to force the audio to that specific soundcard and because the WMP SDK doesn't let us specify an output device for each instance, our program breaks on Windows 7.  Stream Switching moves all audio for each instance to the newly set default audio device.

    The only way I see to have our application still work in Windows 7 is to have the WMP SDK provide us the ability to specifiy the output audio device for each instance of the WMP SDK unless of course you remove the "Stream Switching" feature...only kidding as it is a nice feature to have from a user perspective.

    Is there anyway you can get this information, to hopefully be implemented, to the Windows Media Player team before Windows 7 hits RTM and this breaks our software and I'm assuming others as well?

    Thank you,

    John
    Tuesday, January 27, 2009 7:58 PM
  • I tried this and it fits my needs. http://voipsipsdk.com/Download.aspx
    Saturday, March 21, 2009 5:29 PM
  • Hi mr.India I'm trying this solution long time... could you help me in achieving this... If you could provide me with working code, it would be of great help. I'm new to learning COM and reverse engineering. Thanks
    Friday, July 03, 2009 12:00 PM
  • It's very argent for me. Is there a way to actually modify programmatically values of this key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\ ?


    Wednesday, September 02, 2009 12:25 PM
  • It's very argent for me. Is there a way to actually modify programmatically values of this key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\ ?



    I would like to know this too.  I am trying to write an aspnet program that will change the audio of the "web server" so i can change the audio device from my iphone.  (how cool will that be?!?!)
    Saturday, September 12, 2009 5:52 AM
  • I've been looking for this exact same functionality as well.
    There is not a single media player out there which exposes the different sound devices in a convenient manner, so that Windows' mmsys.cpl still remains the most accessible way of changing the default output.

    Frequent changes to the default input and output devices are quite common these days. Especially since Windows changes the default sound device any time you plug in a USB sound device. The functionality is nice, but it needs to be programmable.

    I strongly advocate adding these two features:
    * Expose an API for programmatically setting the default audio endpoint.
    * Add a checkbox somewhere nice to toggle said API. (To prevent default audio from being changed.)

    Forcing people to reverse-engineer this stuff is ridiculous. And after all, it's not working as advertised anyway: RtHDVCpl.exe does it, so why can't we?
    Friday, February 12, 2010 5:43 AM
  • You sir, are a genius! ^^
    Thanks , Research is my hobby and job )))


    rus: http://eretik.omegahg.com/
    Thursday, February 25, 2010 10:04 AM
  • I wish Raymond Chen would write about this in his blog, The New Old Thing...
    Could somebody please ask him? :)

    E.g. Exactly why is this API undocumented? Could it be that this "technology" is patented somehow?

    Tuesday, May 17, 2011 1:53 PM
  • Does anyone know how to disable the speaker in the playback devices (through PolicyConfig)? Thanks.
    Friday, June 10, 2011 11:40 AM
  • Does anyone know how to disable the speaker in the playback devices (through PolicyConfig)? Thanks.


    PC-speaker ("beeper")? Nohow. Interface does not control speaker. Try:
    OpenService(..., "Beep", ) -> ControlService(.., SERVICE_CONTROL_STOP, ...)

    Friday, June 10, 2011 6:59 PM
  • Great job EreTik! Could you suggest how to change default recording device? Is it possible? Tanx
    Saturday, June 18, 2011 12:07 PM
  • Friday, October 14, 2011 8:26 AM
  • Thank you very much for your awesome work. Is there also a solution for setting the default recording device programmatically?
    Friday, March 16, 2012 10:58 PM
  • Hey EreTIk,

    I had a similar problem and I think your solution will solve it (haven't tried it yet). I was just wondering out of curiosity, how you were able to deduce the CLSID and Interface from the MmSys.cpl. What I'm asking is how you were able to reverse engineer it? I'm amateurish at best in programming and just wanted to expand my knowledgebase. Thanks! 

    Monday, August 13, 2012 4:08 PM
  • Deleted some posts in this thread which discussed a reverse-engineered interface.

    Matthew van Eerde

    Wednesday, November 21, 2012 7:57 PM
    Moderator