This setting here:
I spent several weeks building and rehearsing a presentation to a combination local and remote-meeting audience, and the only thing I couldn't test was the audio feed to the remote-meeting. Because the meeting specifically requires a **sound card** and a **camera**, not a stream, I sent OBS's Monitor output to a loopback that the meeting could pick up, along with the Virtual Camera. So far, so good.
Meanwhile, another copy of OBS (both using the --multi flag on the command line) took either the stream output or the remote-meeting window and both displayed it to the local room and recorded it. A bit of automation with python and websockets, and strategic naming of all the scenes for that automation to pick up on, made it relatively easy to live-produce both the presentation itself and the recording without a second operator.
Since it was the only thing I couldn't test, I didn't realize that most of my featured media only sent audio to the local room (the stream, via another copy of OBS) and not the remote-meeting (the monitor, via a loopback)! One of the remote people told me they couldn't hear anything from it, and I guessed the problem as shown above and fixed it for everything while the next video was playing. (the audio suddenly cut on for them, and everything after that worked) But it sure would have been nice to have it "just work" from the start!
Is there a setting for the default Audio Monitoring for new sources, so that mine can *always* be "Monitor and Output" as I build and rearrange things? I looked around and didn't see one.
---
I'm also a live sound guy, so I definitely understand not sending an open mic to open speakers in the same studio (and not cluttering up that mic either, with unnecessary sound from those speakers), and the current default is perfect for that, but that's not what *I'm* doing with it. I do have an open mic, but it's carefully managed to be okay; as in, local to each scene that uses it and not global, never routed to the local speakers anyway, and ducked aggressively under the remote audio to avoid a distracting echo for them. (if I really want to interrupt, I can mute the remote before the ducker...)
I spent several weeks building and rehearsing a presentation to a combination local and remote-meeting audience, and the only thing I couldn't test was the audio feed to the remote-meeting. Because the meeting specifically requires a **sound card** and a **camera**, not a stream, I sent OBS's Monitor output to a loopback that the meeting could pick up, along with the Virtual Camera. So far, so good.
Meanwhile, another copy of OBS (both using the --multi flag on the command line) took either the stream output or the remote-meeting window and both displayed it to the local room and recorded it. A bit of automation with python and websockets, and strategic naming of all the scenes for that automation to pick up on, made it relatively easy to live-produce both the presentation itself and the recording without a second operator.
Since it was the only thing I couldn't test, I didn't realize that most of my featured media only sent audio to the local room (the stream, via another copy of OBS) and not the remote-meeting (the monitor, via a loopback)! One of the remote people told me they couldn't hear anything from it, and I guessed the problem as shown above and fixed it for everything while the next video was playing. (the audio suddenly cut on for them, and everything after that worked) But it sure would have been nice to have it "just work" from the start!
Is there a setting for the default Audio Monitoring for new sources, so that mine can *always* be "Monitor and Output" as I build and rearrange things? I looked around and didn't see one.
---
I'm also a live sound guy, so I definitely understand not sending an open mic to open speakers in the same studio (and not cluttering up that mic either, with unnecessary sound from those speakers), and the current default is perfect for that, but that's not what *I'm* doing with it. I do have an open mic, but it's carefully managed to be okay; as in, local to each scene that uses it and not global, never routed to the local speakers anyway, and ducked aggressively under the remote audio to avoid a distracting echo for them. (if I really want to interrupt, I can mute the remote before the ducker...)