Disabling Audio input/output (Microphone/Speaker/etc) in Device Manager does not disable device in Sound Control Panel or stop audio...oh my!

Question

In Windows 10 (1803 build 17134.228), I open both "Device Manager" (devmgmt.msc) and the "Sound Control Panel" (mmsys.cpl).

Both Device Manager and the Sound Control Panel show the same audio input/output devices.

ex: "Speakers" and "Microphone".

This is good!

In Device Manager, I disable "Speakers", which continues to show up and has an icon showing it is disabled.

In Sound Control Panel, "Speakers" still shows up and *is not disabled*!

When I play a sound through the [disabled in Device Manager] Speakers, I can still hear the audio!

This is horrible!

In Device Manager, I re-enable "Speakers".

In Sound Control Panel, I disable "Speakers".

In Device Manager, "Speakers" disappears as an Audio output device.

Audio correctly cannot be heard.

This is good!

In summary:

1. Why does disabling "Speakers" in "Device Manager" not stop audio coming out of them?
2. What does disabling "Speakers" in "Device Manager" actually do?
3. Why is disabling Speakers in Device Manager different than disabling Speakers in Sound Control Panel?

Now for the real meat: I am trying to disable/enable the Audio input/output device...

...the way that the Sound Control Panel does...

...but programmatically (PowerShell, C#, C...whatever works).

There are many of examples of how to disable/enable a device that involve "devcon.exe disable/enable", "Get-PnpDevice | Disable/Enable-PnpDevice", and "Get-Device | Disable/Enable-Device".

All of these result in the device being disabled in the Device Manager, and exhibiting the above undesirable behavior; the audio devices still show up in Sound Control Panel and are usable. :(

I also have tried the Registry hack (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture{GUID} DeviceState=1 or 10000001), but that seems to be a cosmetic hack only and doesn't actually force close any open devices or prevent new opens.

So I'll add another question:

1. How can I programmatically disable/enable and audio device to have the same effect as doing it in Sound Control Panel?

And no; UI automation of the Sound Control Panel is not an acceptable answer.

I am looking for an actual API that can be called in the background, not a horrible UI hack that requires being in the foreground.

Thanks!

Pv

Answer 1

Looks related to the unresolved but locked Can't disable playback devices

Answer 2

It is unlikely that anything outside of the signed driver or a signed app with admin access to the driver (e.g. coinstalled) can disable an audio device or more specifically an endpoint (headphones, speakers, etc).

Imagine some random application being able to mute audio for other apps.  

You can enumerate endpoints in your application and choose an endpoint or explicitly avoid rendering to a specific endpoint.  If WASAPI doesnt have what you want to execute that logic, that interface may not be available.

https://docs.microsoft.com/en-us/windows/desktop/CoreAudio/wasapi

If you can provide more details on the scenario it might be easier to find what you need.  😄

Answer 3

Thanks Clint (I was told to expect your response).

Understood about the undesirable ability for some random app to mute/disable audio for other apps.

An even worse case would be for some random app to *enable* a device that the user wanted disabled (ex: Microphone, WebCam, etc).

But the user can do this with a zero elevation prompts from the system Sound Control Panel (what I am calling the "Settings -> System -> Sound" control panel).

If a random app/script doing this were really a concern then I would expect any sort of "UAC" type of prompt when disabling or enabling the device.

I understand that the Sound Control Panel is a signed system app and perhaps running with elevated permissions...

...but with no security prompts when launching the control panel or applying these settings, there is never any conveyance to the user that anything risky is going on here.

I would think if I wrote an app/script launched as Admin and that passes the UAC prompt, it should be able to disable an individual sound playback/recording device.

Theoretically (I haven't written the code to prove this) I believe that it is currently possible to disable/enable an *entire* USB device...

...so why would disabling/enabling subcomponent individual Playback/Recording device interfaces on the USB device be *more* restrictive?

As my original post indicated, the individual Playback/Recording interfaces can be "Disabled" in the Device Manager...

...but that seems to have zero effect! Audio can still be recorded!

https://www.youtube.com/watch?v=Uk1RfU7-bKE

That right there seems like a major major serious security bug to me!

Headline: White House conversation recorded on Windows PC that had microphone disabled. :)

Stepping back, my scenario is a domino effect of several issues, the first few of which I wouldn't expect Windows/Microsoft to handle.

I will tell you the full scenario, but I hesitate to because it may seem to an outsider as unnecessarily complex, but I can assure you that each issue along the path seems orthogonal to successive issues.

If any step along the below path could be fixed/avoided, then my use-case scenario might start to work with no issues.

That said, here is my full TL;DR scenario:

1. I have a USB headset that for live production reality reasons I need to remove occasionally and eventually re-insert occasionally.

Find a way to avoid this requirement is moot; This requirement alone should be nothing that Windows cannot handle.

I must be able to remove and re-insert the headset on a regular basis without any manual intervention required (any intervention must be scriptable).

The reason for this requirement is because the headset is actually behind a USB A/B switch between two PCs.

(The USB A/B switch is *not* the cause of any proceeding problem; the proceeding problems occur considering only a single PC with the headset removed and eventually re-inserted.)

Sharing the headset between two PCs is admittedly a superficial gimmick; I could have two headsets, one connected to each PC, but then I would have to regularly physically take one headset off and put the other one on.

I insist on using one headset, not two; Windows should be able to handle this scenario.

Now you see why I hesitate to give you too much detail? :) 2. I have a niche 3rd party audio effect app that live streams/records from the USB headset's microphone.

The app has a bug that fails to gracefully re-open a microphone if it is removed and eventually re-inserted.

(I have contacted the app's developers asking for a fix, but have zero expectations that they will).

One obvious fix for this is to close and re-launch the app; I have scripted this and it is my current solution/implementation, but the app has an annoying "feature" that forces a mandatory splash-screen in to the foreground, so I have to manually alt-TAB back to my live production full screen app.

It is an understatement to say that this is highly undesirable in a live production screencast environment. 3. My PC already had 5 Virtual Audio Cables installed, so instead of having the app directly open a removable USB headset microphone, I have it open a persistent virtual recording input, and I set the USB headset's microphone's properties to "Listen to this device on" the output of that virtual recording input's output.

This works because the virtual cables' inputs/outputs share the same virtual bus (ie: they loopback on themselves).

Once manually set there is no issue with this configuration. 4. However, after any time of removing and re-inserting the headset, Windows non-deterministically most of the time fails to honor the "Listen to device on" in a timely manner, if at all.

A manual workaround for this seems to be to manually disable the microphone's "Listen to device on" setting, and then re-enable it...

...but, there is no API to automate this setting. :/ (UI automation is not acceptable)

Another manual workaround for this is to disable the microphone and re-enable it.

The only obviously documented way to do this affects the device in Device Manager, but as the OP states this has no actual affect on the device!

There appears to be some programmatic way to affect the device do this via SetupAPI or CfgMgr32, but I wrote a C# app that runs as Admin and pinvoke's CfgMgr32 and am currently getting CR_ACCESS_DENIED when trying to set DEVPKEY_DeviceInterface_Enabled on any KSCATEGORY_CAPTURE or KSCATEGORY_RENDER device.

https://github.com/paulpv/WindowsAudioDeviceManager

FML? :)

Pv

Answer 4

I made a discovery last night that makes me have to correct my story a litt

I said:

4. However, after any time of removing and re-inserting the headset, Windows non-deterministically most of the time fails to honor the "Listen to device on" in a timely manner, if at all.

What I discovered last night while trying to video capture a repro of the problem of the "Listen to this device" setting *rarely* taking affect is that it actually fairly consistently does always take affect after ~8-10 seconds.

Again, before I could swear that I had been observing that Windows almost never honored this setting when a device is re-inserted.

I am now unable to repro that, which I felt was an uber-majority of the time, and instead am almost always seeing an 8-10 second delay before the setting is honored.

I *sometimes* (guesstimating <20% of the time) see it take less than a few seconds for Windows to honor this setting, but most of the time it takes ~8-10 seconds.

I captured a video of the delay here:

https://www.youtube.com/watch?v=tg0y1taFyDE

I can live with a ~9 second delay and just find some way to handle the dead mic time in the live stream, but it seems like this setting should kick in consistently almost instantly.

If I ever repro the setting never kicking in, or taking more than 10 seconds to kick in, then the scenario becomes unusable and I have to resort to hacks such as disabling and re-enabling the device in an attempt to force the setting to take affect.

Pv