Can this shitty program stop randomly changing input devices to the Default one?

[mrakgr]

I am fucking pissed off right now.

I spent the last 25m talking into the camera in a casual fashion, letting things come on their own and when I added the clip to the timeline, it turns out there was no audio. I took a look at the OBS, and sure enough the bar was grayed out. It only became green once I switched the input device to my MIC.

This wasn't the first time this happened.

Couple of weeks ago, I did a week worth of screencasting on my Youtube channel only for there to be no audio. I had to turn the entire thing into a timelapse while putting some random music in the background.

Now instead of programming, I am writing this post and need to take a break so I can stop being so angry.

...

More constructively, I am trying to investigate this now and it's weird. I cannot actually disable the audio input by switching back to Default.

Sometimes it simply switches to Default and becomes disabled, and I can get it to work by selecting the specific mic that I have. After that I see that it's taking in input from the mic based on the bar. That is the case right now.

Is maybe updating OBS that is causing this? Or maybe restarting the computer? I am not sure. I'll try the later, but it's probably not it.

I am looking at the recording right now and I see that when I started it, the MIC bar was in fact green. I tried pasting a screenshot to show you, but the forum file limit is too low.

I'll try disabling it and turning the computer on and off.

 

[mrakgr]

No, I can't figure it out. Maybe an occasional update somewhere is causing the MIC to be set to null under the hood. Merely restarting or fiddling with enabling or disabling the input sources is not enough to trigger this error.

 

[John Hartman]

In my experience, sometimes Windows Updates cause USB audio devices to be re-enumerated and assigned different IDs. OBS identifies the devices by ID, and can't find the device, so you get no audio. Annoying, but it doesn't happen often (at least on our setup), and easily fixed.

To avoid this messing up a stream, we
1) postpone Windows Updates to the max limit (about 30 days), and manually do the update at a convenient time before that date
2) after the update, verify that everything works. Then postpone updates for next time.

 

[koala]

More constructively, I am trying to investigate this now and it's weird. I cannot actually disable the audio input by switching back to Default.

Some info about audio device selection and activation, may be you're able to relate this to your situation.

At OBS startup, OBS will do this:

• if you have some audio device set as "default" and not directly configured with the device name, OBS will determine the current Windows default audio device and use this for the rest of the OBS session (or if you manually change it to something else). If you plug in or switch on some new device, and this device becomes the Windows default device, OBS will not follow this. It will stick with the previously determined device.
• if you configured some audio device directly with the device name, OBS will try to initialize and use this device. If it's present, it will use this device. If it's unable to initialize, this source will stay silent and inactive.

About such a silent and inactive audio device:

• if you have such an inactive source and its device is switched on or plugged in while OBS is already running, OBS tries to initialize the device. If it's able to do this, this source becomes active and will be used by OBS from now on. If it's not able to initialize this device, the source stays silent and inactive.
• if you open the properties of such an inactive source while it is inactive, OBS will show "[Device not connected or not available]" if it is configured in Settings > Audio > Global Audio Devices. However, if you configured the source as audio input capture source, it will show "Default" in the source properties. If you now leave the property window of the audio input capture source by clicking "OK" (and not "Cancel"), it will save this "Default" as device name instead of keeping the silent and inactive device name. OBS will determine the default Windows device in this moment and use this device for this source for this session and will automatically determine the default Windows audio device on subsequent OBS starts. The original device assignment is lost.

What you should do to avoid speaking into a mic that's not used by OBS:

• always use global audio sources and no audio input capture/audio output capture sources unless you have sources you want to appear only in some but not in all scenes.
• connect and switch on every mic device before you start OBS. If in doubt, restart OBS before using some mic you just switched on or plugged in
• always leave property/configuration windows with "Cancel", never with "OK" (unless you want to actually save a change you made, of course).
• make it a habit to check every mic meter in OBS if it's really picking up sound from your mic by snapping your fingers in front of that mic or tap it until you see the bar. Don't start recording/streaming unless you verified the meter.

 

[mrakgr]

Thanks for the replies.

Instead of the input devices being keyed to an underlying id which is unstable, why not use the device name instead? On my rig both the Default and the Microphone(AT2020USB-X) point to the same input device, and are the only input devices, so in no circumstance should the input fail to go through in OBS. Would this be hard to implement?

After losing a week worth of audio recordings, I've learned to check, but I missed it one time which inspired me to write this post. It shouldn't be necessary for the user to be on guard so much.

 

[Lawrence_SoCal]

Sorry, I get being frustrated, but your reply indicates you have NO IDEA how Operating Systems work.
Your issue isn't the application (OBS Studio, in this case), but the OS. And there are lots of REAL good reasons common name is NOT used as authoritative (think multiple of same device) [look up lots of prior threads on basically same issue].
So, if you want Microsoft (in this case, but issue is NOT unique to MS,) to change how they operate their Operating Systems kernels, feel free to contact them and let us know when they agree to change OS low-level h/w interface design (the base approach predates Windows, btw)

In your case, you've learned that any USB device can get re-enumerated after a reboot. so, it is up to you to check/confirm applications still point to same USB device. You could say 'But I don't have to do this with other apps' and you'd be right. BUT, (if true) you aren't also using application that need such low level device control (no, you may not be doing something that requires a Device lock, but some features of OBS Studio do) that requires a bit more specificity.

Again, I get your frustration... but you are using a free, open-source tool, which is quite flexible and powerful, designed for user interactive compositing, that requires a LOT more user attention than a typical hand-holding application.

 

[proxypunk]

You can ask around if streamers are disappointed by having to recheck if their audio device is still set every time they start the program. At least you should get some kind of error message or warning (or have the choice of opting this in or out) if a device isn't present anymore...

 

[Lawrence_SoCal]

At least you should get some kind of error message or warning (or have the choice of opting this in or out) if a device isn't present anymore...

That does sound like a nice suggestion. Mind you, I'm just another user... I believe your suggestion would be best posted to GitHub (probably) or the Ideas and Suggestions forum https://obsproject.com/forum/list/studio-feedback-and-suggestions/

From a UI consistency perspective, leave behavior as it is now, makes the most sense. But having option to enable a check and corresponding warning makes some sense... BUT, also consider that all Scenses get rendered, so a visual warning indicator on a source wouldn't be visible until you changed to that Scene... and OBS Studio has no idea which Scenes you will or won't use during a given session... just things to think thru when making suggestion on desired behavior

 

[smitho]

I would be in favor of a warning that appears when you select a scene if any of the sources in that scene changed because it was not available. We use OBS for streaming a church service and this bites us occasionally. We have so many things to check every week that sometimes we forget to see if our audio sources went back to default.
The first scene we use only has a loop from an MP3, so when that works and our volunteers see the audio coming through they often assume everything is fine. When the scene switches to one with a camera and audio from a USB audio interface they often don't realize audio is not coming through because at that point they are having to focus on mixing sound.
We click through scenes and check that our cameras are working prior to going live, but it could be quiet at that point and not notice there is no audio coming through.
There is enough people that struggle with this that it should be addressed in some way. Even if you didn't get the warning until you select the impacted scene, that's better than nothing.

 

[bcoyle]

Sometimes, this is a procedural problem. Any concert/venue/church needs to do a sound check. I know at our church, we have a number of older volunteers, that might have trouble with that. They get very stressed, when things go wrong. Maybe a checklist, something like a pilot - pre take off. 15 minutes before the serve starts.

 

[konsolenritter]

And as koala already suggested: "always use global audio sources and no audio input capture/audio output capture sources unless you have sources you want to appear only in some but not in all scenes."

That is even more important for concert/venue/church environments. Nobody would seemingless switch-off and -on again his sound mixing bord during the transmission, isn't it? The very same should be applied to audio sources in OBS! Here's why:

So - strong hint: Apply a reliable and lasting link between your soundboard and OBS, hence using global audio source for the appropriate device. It should be a reliable one, if not the most reliable of your whole signal chain, including audio AND video. I say this as a cameraman and picture director as well as recording director of a yearly summer event of 2000+ people. Furthermore:
Regarding audio then its good practice to have a hand on channel faders and/or mutes (i personally prefer downing the faders because you can /see/ minutes or hours later if and what a sound source is weak or was lowered on purpose; preventing the BLIP-N-CRASH switching-in of audio sources if you're late or in hurry - pastor already speaking, choir already singing aso.) You know such situations for sure.

Even more there could or shall be a well defined atmo source, for instance a distant (uncorrelated) room mic that keeps /always/ on with 12 or 15 dB lowered in comparison to the typical main sources. For sure this room mic should be routed only and only into your subgroup for streaming/transmission, NOT the local P.A. (sound reinforcement in the hall/venue/church).

Thats for more than one single reason: If your main source drops (for whatever reason) mid transmission your audience don't fall into totally dead silence, preventing them from thinking that their communications end or equipment died. So they keep calm. The second reason is regarding the video sources. If your cam or video switcher goes black (for whatever reason) the people still hear the audio from your location. So they dont fall into totally... you know.

So its the responsability of the sound guy to open or close audio sources - accordingly for the remote audience as well as the local sound reinforcement in the venue/church.

Switching on and off audio sources by switching scenes is one of the most nasty moments for the audience, at least due to (most often) changing volumes/loudness of different sources. So prevent this whenever you can.

And the "soudcheck" for OBS then often reduces to take a wireless mic (as needed for the local soundcheck as well), simple and soft tapping onto it to see if the sound is coming thru the chain down to OBS level metering. Then you may go...

 

[bcoyle]

And as koala already suggested: "always use global audio sources. Agree. We use 2 audio boards. One for venue EQ and one for streaming. We have a different operator on each one. The audio boards take input from the stage and our graphics pro-presenter. The audio goes to our black magic video switcher. The video switcher only uses the video part of each camera. There are 2 extra video feeds from the pro-presenter, graphics and text overlays. The switcher output is sent to our obs computer.

The problem with global audio input has been the different camera/pro-presenter video frame delays, i.e. lip sync problems. We have had to characterize all our delays, (video is always later compared to audio) and then pick an audio delay compromise. The worst offender is our roaming camera with a wireless connection.

 

[konsolenritter]

That different delay issues i know for sure. For my main yearly event (a "tent" city with 2k people) we had to choose two similar panasonic cams for the main cams to have nearby the same delay. We were astonished to see that the two cams, one AG-UX and one HC-X1 had exactly the same delay, even one has SDI output and the other HDMI which has to be converted by an BMD converter first. So it was astonishing that the difference between SDI and HDMI is neglectable, but different generations of cams bring in dozens of frames difference. Really sick.

One year i was forced to use two different generations of pana cams. I dialed the tradeoff between the two delays into an delay filter in obs. sitting in the middle. So one cam was a bit early, the other a bit to late. Both remaining delays were unremarkable for the most people, luckily.

And yes. Stagecam with wireless 5G digital transmission are fine, but worse in delay. The best in this case are slightly older, used wireless cam transmitters that work analogue (smaller propagation delay).

But this conversation is a bit off-topic now. We should return if possible. :D

 

[konsolenritter]

The audio goes to our black magic video switcher. The video switcher only uses the video part of each camera.

Thats the only thing i would mention the other way round. Leading the audio thru the BMD videoswitcher makes this machine a single point of failure. Its the pleasant way to take the single connection from the mixer (atem?) for both the video and audio part. But this has a couple of downsides indeed.

But rethink: In terms of ms windows (hence obs) means that the driver architectures of handling audio and video devices in the os are totally different. This means that the signals reach for the pc the very same moment but are separated afterwards. Only in the very last stages (muxing the streams in obs finally) will recombine them really.

If for some reason the mixer connection drops both signals will fail at once! Furthermore, in case of using USB these devices drop completely and will be unreachable for their drivers. Even if you reboot or reconnect the mixer very fast, the connections in obs must be reestablished manually by hand often. So this costs time and two people (at least) are in hurry about rebuilding the connections and reach for the former state.

Thats why i prefer to use separated stable media converters. For an Atem SDI for instance i use an AJA U-Tap to the computer, for the audio path an RME fireface to the computer. If the video connection drops before, within or behind the video mixer, the usb input device gets a test signal internally from the aja. The connection remains. If the sound drops, the rme interface will survive and keeps connected. Nothin on windows/obs side must be restarted or changed. If the video drops for the moment, the audience keeps connected by working audio.

Even if the complete video mixer must be rebooted mid transmission, only the video feed drops for a moment the mixer needs to restart. No single usb disconnect. Hence minimal recovery time for the machinery, the audience and (at least) myself.

 

[bcoyle]

Thats the only thing i would mention the other way round. Leading the audio thru the BMD videoswitcher makes this machine a single point of failure. Its the pleasant way to take the single connection from the mixer (atem?) for both the video and audio part. But this has a couple of downsides indeed.

But rethink: In terms of ms windows (hence obs) means that the driver architectures of handling audio and video devices in the os are totally different. This means that the signals reach for the pc the very same moment but are separated afterwards. Only in the very last stages (muxing the streams in obs finally) will recombine them really.

If for some reason the mixer connection drops both signals will fail at once! Furthermore, in case of using USB these devices drop completely and will be unreachable for their drivers. Even if you reboot or reconnect the mixer very fast, the connections in obs must be reestablished manually by hand often. So this costs time and two people (at least) are in hurry about rebuilding the connections and reach for the former state.

Thats why i prefer to use separated stable media converters. For an Atem SDI for instance i use an AJA U-Tap to the computer, for the audio path an RME fireface to the computer. If the video connection drops before, within or behind the video mixer, the usb input device gets a test signal internally from the aja. The connection remains. If the sound drops, the rme interface will survive and keeps connected. Nothin on windows/obs side must be restarted or changed. If the video drops for the moment, the audience keeps connected by working audio.

Even if the complete video mixer must be rebooted mid transmission, only the video feed drops for a moment the mixer needs to restart. No single usb disconnect. Hence minimal recovery time for the machinery, the audience and (at least) myself.

I'm not sure what you are saying. The audio mixer board, the video switcher, the pc with obs, the external internet connection are all single points of failure. WIth 5 cameras, the audio always has to come from the audio board. All our camersa are SDI inputs, even pro-prenter. THEY ALL HAVE video lagging the audio, which is real time. The video switcher has a optional audio delay that is "REQUIRED" to offset the audio to match with the delayed video. The output of the switch is SDI and sent to OBS, with audio embedded. If the switcher fails, you are in big dog dodo anyway. Normally you just power cycle it. But the blackmage switcher is pretty darn professional and has never failed. We have more trouble getting youtube started occasionally by some of volunteers. That is a single cause of failure. It does mean they need more training.