OBS Studio (win) reverts audio device to default

[mab42]

Hi,

(I am posting this under "Development" as it seems to be a more technical question that might best answered by someone close to OBS development. Feel free to move this request if this is not appropriate.)

We are using OBS Studio 27.1.3 on Windows 10 for a video conferencing setup, i.e. we stream OBS audio and video into zoom, and are generally quite happy with it. Unfortunately, once in a while OBS changes our audio source back to "Default", and with that also audio monitoring settings. This causes the entire audio signal to get lost - which is not a good thing a few minutes before a presentation starts.

To make this more "fun": the problem is hard to reproduce, so I have to work without a test case for now.

The audio device in question here is a Dante AVIO USB adapter which receives audio via TCP/IP and presents it to the Windows system as USB audio device.
For some reason, OBS seems to not to always "find" that device (might be the device's fault?) and then it switches the Audio Input Capture source (wasapi_input_capture) to "Default". And once it does that, also the Audio Monitoring settings for that source are switched from "Monitor Only" to "Monitor Off". And those changes seem to be sticky, i.e. when using the system in the next day, audio is still set to "default" even if the Dante USB device is working perfectly fine (in such a case: if we manually adjust the OBS config in the source, in the Advanced Audio settings and in the Preferences, everything works perfectly again, without having to restart OBS, Windows or any device - so it looks like only the OBS settings are faulty).

In order to debug this, I would like to better understand what OBS is doing with its devices when starting up and which files are used to store those settings.

• Where does OBS learn which devices to use for which source?
• How does OBS try to detect/find a device?
• What causes OBS to not "find" a device and then switch to "default"?
• What does the log entry:
  [WASAPISource::WASAPISource] Device '{0.0.0.00000000}.{86154005-5f10-4c00-925c-098dc8b4b7d6}' not found. Waiting for device
  mean, and how can I find out which device this is?

Unfortunately, I do not have a log file yet for the error case (as mentioned, it is hard to reproduce).

Since the system is accessed through a shared Windows user, we might just replace those config files upon each login if necessary.
So far, I found these files to carry some of the audio config:

• C:\Users\username\AppData\Roaming\obs-studio\global.ini
• C:\Users\username\AppData\Roaming\obs-studio\basic\profiles\Untitled\basic.ini
• C:\Users\username\AppData\Roaming\obs-studio\basic\scenes\Main_Collection.json

Thanks in advance for any suggestions how to solve this!

 

[John Hartman]

For better or for worse, active support for OBS issues happens mostly on Discord, so you might try there.


Have you noticed any correlation between this problem and Windows updates (Patch Tuesday on the second Tuesday of each month)?
We are using a USB hardware devices for audio and cameras, and three or four times in the past year we have had an audio problem after Windows update.

• sometimes changes the audio interface input from stereo to mono
• sometimes loses the interface or camera, as is happening with you

My assumption is that Windows is doing a new enumeration of devices, and the GUIDs stored by OBS are no longer correct.

We cope by keeping Windows updates paused (you can postpone by up to a month). Then at a convenient time after Patch Tuesday (and NOT just before a stream...) we enable and perform Windows updates, verify that OBS is still happy, and pause updates again.

 

[mab42]

Thanks very much for your help!
(Discord, um, really? I much prefer a forum like this)

Your idea of Windows updates and USB enumeration sounds really relevant, thanks very much.
Could you help me to find those enumerations so i can compare them before//after? Or would there be a way to detect those changes, e.g. in Event Manager?

Where does OBS look for them? And is there a way to tell OBS not to use GUIDs but maybe device names? Luckily, we do not have two identical audio devices on the system.

 

[John Hartman]

The short answer is I don't know whether it is possible to avoid the issue. We just delay Windows updates, and test OBS after we finally do them, fixing problems if there are any. Since one of our issues has been Windows turning a stereo input into mono (Windows Sound Settings, Advanced), we have to look beyond OBS anyway.

If you want to go spelunking, the current settings are all in your scene collection file. But the file is minimized json, so you need an appropriate editor.
As your original post showed, if a Windows update changes your camera or audio device's identity, OBS will most likely flag the "can't find it" error in the log file for that run. But the log won't show the device's new identity.

 

[mab42]

Cheers! Unfortunately I need to wait until it happens again in order to get a log file...

This is the section of the JSON file that I believe describes our microphone (I have removed the filters and the hotkeys for brevity):

{
    "balance": 0.5,
    "deinterlace_field_order": 0,
    "deinterlace_mode": 0,
    "enabled": true,
    "filters": [
        ...
    ],
    "flags": 0,
    "hotkeys": {
        ...
    },
    "id": "wasapi_input_capture",
    "mixers": 255,
    "monitoring_type": 1,
    "muted": false,
    "name": "Sennheiser TCC2 In",
    "prev_ver": 453050371,
    "private_settings": {},
    "push-to-mute": false,
    "push-to-mute-delay": 0,
    "push-to-talk": false,
    "push-to-talk-delay": 0,
    "settings": {
        "device_id": "{0.0.1.00000000}.{fc6c6f65-f3b9-4c87-8d79-8e29e37ce2ef}",
        "use_device_timing": true
    },
    "sync": 0,
    "versioned_id": "wasapi_input_capture",
    "volume": 1.0
}

I assume the "device_id" is what OBS is using under the hood to identify the device?
If so, where does that number come from? Any idea where in Windows I could be looking for it?

Maybe someone familiar with the source code could identify the part where the JSON file is loaded and what the "device_id" attribute is used for exactly?

I gave it a try and found the method WASAPISource::UpdateParams WASAPISource::BuildUpdateParams(obs_data_t *settings) in ./plugins/win-wasapi/win-wasapi.cpp which used the string labeled OPT_DEVICE_ID to populate the UpdateParams struct.
Then InitDevice uses the device_id member variable, and eventually it seems to end up in the IMMDeviceEnumerator interface's GetDevice method. In this method, something called "Endpoint ID Strings" is used:

The endpoint ID string for a particular audio endpoint device uniquely identifies the device among all audio endpoint devices in the system.

[...]

The lifetime of an endpoint ID string is tied to the device installation. The endpoint ID string of a device changes if the user upgrades the device driver, or if the user uninstalls the device, and installs it again. However, the endpoint ID string remains unchanged across system restarts, and the endpoint ID string of a USB audio device remains unchanged if the user unplugs the device and plugs it back in.

But all that still does not tell me where in Windows I might find those... (maybe https://www.beyondlogic.org/usbnutshell/usb5.shtml helps?)

This looks quite promising https://www.uwe-sieber.de/usbtreeview_e.html but not sure what of all that data maps to "Endpoint ID"...

 

[John Hartman]

Searching the Windows Registry for the GUID portion of OBS's device_id for my audio gets a number of hits, but I have no idea what any of them mean. The GUID in the device_id for my camera matches one of the strings shown by Device Manager properties for the camera, but I don't see a similar match for my audio device.

Perhaps some Windows updates "upgrade the device driver", or "uninstall and reinstall" some devices. Driver updates for security or bugfix seems not unlikely.

 

[mab42]

Since this has happened to us now again, here is a followup, in case anyone reads this:

Chances are very high this loss of device in OBS is indeed caused by a Windows update - we can pinpoint the failure down to a 12h time window, during which the Feb 14 updates were installed and the machine rebooted.

Looking more closely, I found that KB5022834 did indeed bring an updated version of usbccgp.sys (in our case from 10.0.19041.1949 to 10.0.19041.2546) which seems to be a generic USB driver.

I need to do one final check on the USB IDs used by OBS but this all sounds very plausible.

The next question would be: How can we make OBS more robust to these changes?

 

[John Hartman]

It happened to us as well after Tuesday's update.

While it would certainly be NICE if OBS could cope, at least in our setup it wouldn't be possible: in addition to changing the device identifier, Windows update changed the interface from stereo to mono. We use the left channel for feed from our sound system, and the right channel for a crowd mic: two audio channels in OBS using the same interface (one panned left, one right) so we can adjust the amount of crowd sound in the stream as desired.

The change from mono back to stereo has to be done in Windows Sound Setting. If you just edit OBS to use the new interface (or if OBS figured it out on its own as you propose), the two channels are identical and our scheme wouldn't work.

I seem to recall that Windows Update has done something similar to our two USB-connected cameras in the past. Since we have two cameras of the same type, I would hate to have OBS "guess" the new IDs and flip them around

And Redmond only knows what else an update might munge. So I'll stick with postponing Windows update, then updating manually after Patch Tuesday and before our next stream. Postponing also helps keep Windows from eating our meager internet bandwidth by downloading updates during a stream.