This project has moved and is read-only. For the latest updates, please go here.

hide application from windows volume mixer

Jun 18, 2012 at 2:44 AM


Is there any way to hide an application, which uses wasapi loopback capture, from windows volume mixer. A more detailed description of the problem is given in the following link:

I will be glad to hear possible solutions.

Jun 18, 2012 at 10:38 AM

I'm afraid I don't know how to do this, and it may not even be possible. You could try asking a WASAPI related question on StackOverflow


Jun 27, 2012 at 3:58 AM

thanks for the reply.

Jul 24, 2012 at 5:16 PM

I don't know how to hide the application panel on the mixer, but if you just want to lock the setting, add an endpoint.AudioEndpointVolume.OnVolumeNotification callback, and change the setting back the way you want. It's not a perfect lock, but it might be good enough.

Jul 25, 2012 at 1:21 AM

Thank you for your reply. I somehow did what you explained but it was still visible and I said "whatever". I am completely over it now :)

You can imagine how much I tried from my words above I guess.

Jul 25, 2012 at 11:53 AM
Edited Jul 25, 2012 at 12:53 PM

It is a bit tricky but not impossible. Assuming you are not writing any malicious code or something to spy on people by turning on the mic or anything, here is how it could be accomplished:

1. Load a dll into explorer.exe and hook into either ShellExecute or CreateProcess. Not sure which, but one of them should work

2. Intercept when sndvol.exe is being started

3. When sndvol process is loaded and starts to accept window events, find it's window handle

4. Find a child window of type TileListView

5. Find a child window of type TileSled

6. Enumerate child windows

7. Find the window handle of the volume mixer tile of your "invisible" app

8. Set it's Visible property to false, Width to 0

9. Slide the remaining tiles to the left to fill the gap

10. Resize & relocate the main sndvol window

11. ???

12. Profit

Jul 25, 2012 at 12:40 PM

on a second thought, I'd probably hijack mmdevapi.dll, and hide my process from the results.

Jul 26, 2012 at 2:18 AM

I think this file is what should be altered

Anyway, thank you for the suggestions but again application of these methods require more keyboard crunching then what I was actually doing. Besides there are a wide variety of audio applications that are visible in sound mixer popup, so why bother to be invisible.

Jul 26, 2012 at 9:55 AM
Edited Jul 26, 2012 at 10:56 AM

I think I didn't explain it clear enough. I posted the wine library as a starting point, however modifying mmdevapi code and replacing the entire dll would take longer to complete. I will explain it a bit later, but after a little googleing, here is what I found about how sndvol acquires a list of apps that are using sound hardware.

I think the legitimate way of getting the audio apps would be something like this (which I believe it's what sndvol.exe does. Just do a google search for IAudioSessionControl and sndvol. need to attach a debugger to see what it really does):

1. Instantiate IMMDeviceEnumerator (CoCreateInstance, declared in mmdeviceapi.h in Windows SDK)

2. Call IMMDeviceEnumerator::EnumAudioEndpoints to get a collection of IMMDevice

3. Call IMMDevice::Activate to get an instance of IAudioSessionManager2 (declared in audiopolicy.h)

4. Call IAudioSessionManager2::GetSessionEnumerator and get an IAudioSessionEnumerator

5. Call IAudioSessionEnumerator::GetCount and

6. Iterate from 0 to count and call IAudioSessionEnumerator::GetSession to get IAudioSessionControl for each session (The apps that appear in sndvol)

What we want to do is, somehow modify IAudioSessionEnumerator::GetCount so it returns (the correct value - 1) if our app is running, and modify IAudioSessionEnumerator::GetSession to not return the session of our app.

Method 1:

Like you said, you could modify Wine code to create a proxy dll which does the audio session filtering. But then you'd need to create proxy classes for the chain I mentioned above, and detour LoadLibrary method in sndvol process in order to load your own mmdevapi.dll when it starts up.

Method 2:

Alternatively, you can find the offsets of the two methods I mentioned in 5 and 6, and detour them in sndvol. Which I believe wouldn't take more than a couple hours to code using IdaPro/ollydbg & EasyHook/detours/whatevs