Windows Volume Mixer Control in Potato

[Vincent Burel]

With Voicemeeter Potato, the Audio Applications connected to virtual inputs are displayed with a small volume slider and mute button to control what Microsoft calls Audio Session Volume Control (also represented by Volume Mixer). It seems it does not work well with Windows Media Player:

SessionControlISimpleAudioVolume.jpg (126.4 KiB) Viewed 7908 times

When changing the volume on Windows Media Player, it changes on Windows Volume Mixer and Voicemeeter.
When changing the volume on Windows Mixer, it changes the volume on Windows Media Player and Voicemeeter.
When changing the volume on Voicemeeter, it changes the volume on Windows Mixer, but not on Windows Media Player.

[Vincent Burel]

Since Microsoft cannot explain us why directly, we have built a minimal program to isolate the problem: VolumeCTLTest.exe will simply get the first Connected Application on Default Playback Device and simply manage Volume & Mute Control.

WindowsMixerVolumeCtrlTest.jpg (152.33 KiB) Viewed 7907 times

To perform the test with VolumeCTLTest.exe program:
1- Define a default playback Device (if not already done).
2- Run the Windows Media Player (expected to output sound to default playback device).
3- Run VolumeCtlTest.exe (that should detect the Windows Media Player Audio Session as shown on picture above).
4- make test on Volume / mute change on both application (also on 3 application with Windows Volume Mixer).

PROBLEM: When changing Volume / Mute on VolumeCtlTest.exe, Windows Media Player does not react (reproducible on WIN7, WIN10 32/64 bits).

Download EXE and 'C' Source code in this ZIP package:
https://download.vb-audio.com/Download_ ... _pack1.zip

[Vincent Burel]

the first explaination is given by the Wnidows Media Player Session Identifier that is not the right one and should be
{0.0.0.00000000}.{11114d10-a1d2-473d-afae-46295b6f2614}|#%b{512DD86C-6462-4993-964E-ACFA69F9A348}

Since we get the wrong session, it cannot work correct. The rigth Session is a "MultiProcess" one not taken in account in our source code example because IAudioSessionControl2::GetProcessId does not return S_OK but AUDCLNT_S_NO_SINGLE_PROCESS (0x0889000D)

If we change this in our source code to consider MULTI PROCESS session, and if this session comes first in the enumeration, then we get the right session and it works. But the problem remains: How to make the difference between the right Windows Media Player Audio Session and the wrong one(s) ?

WindowsMixerVolumeCtrlTest2.jpg (149.22 KiB) Viewed 7864 times

Download last EXE and 'C' Source code in this ZIP package:
https://download.vb-audio.com/Download_ ... _pack2.zip

[Vincent Burel]

The reply to this problem is "take GroupingParameter in account"
1- all AudioSession with the same GroupingParameter GUID must be grouped in a single volume/mute strip
2- to change volume/mute parameter must be done to all AudioSession with the same GroupingParameter GUID.