Making Voicemeeter automatically detect headphones

[zarquan]

I am using VoiceMeeter for a different reason than most I think. My headphones regularly come unplugged due to a mildly damaged headphone jack and it crashes my DoTA and some other games and applications due to a driver issue I can't seem to diagnose. I am using VoiceMeeter as a go-between. This solves the problem of my applications crashing, but when I plug back in my headphones, I have to leave the application, go to VoiceMeeter, and tell it to use the headphones again.


Is there a way I can tell VoiceMeeter to use my headphones as its primary output so that it picks up the headphones even when they are unplugged and plugged back in?

I am new to this software (and pretty much all sound software), but I didn't see anything obvious that had the effect I wanted.

[Andres]

Hi. This is not the answer to your question but a simple comment assuming you are using the motherboard integrated audio solution: In most desktop PCs headphones connect via a 3.5mm stereo jack on front panel which typically includes jack-detection capability. Some audio drivers allows you to disable front panel jack detection which could be helpful is that is your case. One example using Realtek Audio Console:

disablefrontpanaljackdetection.png (43.4 KiB) Viewed 14177 times

[zarquan]

Hi. This is not the answer to your question but a simple comment assuming you are using the motherboard integrated audio solution: In most desktop PCs headphones connect via a 3.5mm stereo jack on front panel which typically includes jack-detection capability. Some audio drivers allows you to disable front panel jack detection which could be helpful is that is your case. One example using Realtek Audio Console:

I should have mentioned that I am on a laptop, so I am using the motherboards integrated sound I assume. I do have RealTek Audio Console, but it tells me that it "Can not detect an RCP service."

But when I plug in my headphones, my sound comes on immediately without VoiceMeeter. I used to have a dialog, but I did something ages ago to get rid of it because I found it annoying. Since the computer automatically knows what to do with the headphones, I don't think this would be the issue.

[Vincent Burel]

the driver is certainely able to detect if the headphone is plugged or not.
Windows can also manage it , since it appears in the device list in Windows Control Panel - Sound Dialog box or example.

but the different Windows AUDIO APIs (used by Voicemeeter) are not aware about device status, plugged or not, off or not, disconnected or not...

[zarquan]

the driver is certainely able to detect if the headphone is plugged or not.
Windows can also manage it , since it appears in the device list in Windows Control Panel - Sound Dialog box or example.

but the different Windows AUDIO APIs (used by Voicemeeter) are not aware about device status, plugged or not, off or not, disconnected or not...

I think VoiceMeeter can tell when it is unplugged or plugged back in because it correctly adds and removes it from its menus. Though if the API doesn't let you get an alert about it, you would have to run some sort of loop to continually check for its existence, so I would understand if it wasn't default. I do think it should be an option, like check every second or so.

[Vincent Burel]

yes we can detect a disconnection by checking the stream continuity.
it allows us to detect a device disconnection, of switched OFF.
this is what we do with the option "Auto restart audio engine" with the output A1.

But to check if the device is reconnected or switched ON, we have to restart the audio engine because the audio stream never comes back if broken by a device disconnection.

restarting audio engine every 5 second when one selected device is not running is not possible, because many people use voicemeeter with several devices, sometimes connected, sometimes not.

The only way to manage this problem correctly is to encourange Microsoft to add a notification in AUDIO API, to inform the client application about device connection / reconnection.

[zarquan]

yes we can detect a disconnection by checking the stream continuity.
it allows us to detect a device disconnection, of switched OFF.
this is what we do with the option "Auto restart audio engine" with the output A1.

That is exactly what I needed! Now I can unplug my headphones and get sound back without leaving my current application! I didn't know what that button did and it didn't work within 3 seconds, so I assumed it didn't do what I wanted (Or I was on A2 because I didn't know there was a difference). Thank you! This almost perfectly solves my problem. Now I can recommend this as a solution to the other people who have this problem.

Is there a way I could make it faster? My headphones aren't usually unplugged for more than a second when this happens and it would be nice to be able to hear sooner.

[LTEAK]

It seems there must be a way around the problem that Vincent has described above, because plug and play is so fundamental to the philosophy of Microsoft in the Windows platform. So at risk of retreading something Vincent has already delved into in his efforts on this (and which may not work as I think it would), here goes:

First (as Vincent will know but others here may not) in Windows Audio API (which he says VoiceMeeter uses) an "Adapter Device" supports one or more "Endpoint Devices" (which may be for example an internal Conexant headset and Conexant mic or something on USB). See attached image. Adapter devices are registered by Window's Plug and Play Manager. Endpoint devices are registered by the Endpoint Manager.

Before enumerating the endpoint devices in the system, the client must first call the API's Windows CoCreateInstance function to create a device enumerator, creating a IMMDeviceEnumerator (a registry of adapter devices). The client then calls the "IMMDeviceEnumerator::EnumAudioEndpoints" method to create a collection of endpoint objects, of which each is an audio endpoint device in the system (e.g. a mic or headphone). After retrieving a collection of endpoint devices, the client can query the properties of the individual endpoint devices. After selecting a suitable device, the client can call the IMMDevice::Activate method to activate the device-specific interfaces in WASAPI, the DeviceTopology API, and the EndpointVolume API.

(Above are summaries of: https://learn.microsoft.com/en-us/windo ... io-devices and https://learn.microsoft.com/en-us/windo ... nt-devices. See also: https://learn.microsoft.com/en-us/windo ... ming-guide.)

So it seems that by polling the above "CoCreateInstance" and/or "IMMDeviceEnumerator::EnumAudioEndpoints" (a doing a bit of extra work) after VoiceMeeter has detected an unplug, it should be able to detect when a selected device has been reconnected by the user. A question with this method is, will either of these calls interrupt the audio stream. E.g., is this like doing VoiceMeeters "Restart Audio Engine", or does this operate independent of a running audio stream?

My apology if I'm off track here, Vincent; I'm just trying to find a way to make reconnections smooth (since those are causing me frustration on my laptop).

[LTEAK]

I'd like to bump the above post up, since there hasn't been a reply. Might the above method be a solution for VM to automatically detect headphones?