rfcs
rfcs copied to clipboard
obsproject
Add RFC: Audio monitoring busses
Description
Add the ability for users to output audio monitoring to multiple devices.
Motivation and Context
Users want to be able to output to multiple audio devices. For example they could monitor the audio with headphones and also output the audio to speakers at the same time. They also don't have to use other software for this.
Link
https://github.com/cg2121/rfcs/blob/audio-busses/accepted/0009-audio-busses.md
I am interested in having the ability to have full, arbitrary control over where every audio source in OBS gets routed.
My specific use case is that a show I work on ingests 4 RTMP streams in OBS as Media Sources. I would like the audio from each of these Media Sources to be routed to a separate Dante audio device, such that our outboard X32 mixer receives the audio of each Media Source independently.
I feel like the concept of busses isn't really necessary. It feels like it adds an unnecessary layer of complexity to the process. I feel like it'd be better to just make it list the devices and it would automatically handle all that stuff internally for the user. Right click -> choose device.
Although I think the first problem we have to figure out first is monitoring on the mixer. I kind of have mixed feelings on the monitoring icon on the mixer. I've actually implemented that myself on a branch in the past but never merged it because of the fact that we have three monitoring states, and because I'm concerned people will turn it on without realizing what they're doing.
So what's a good interim? Maybe we should have monitoring device selection in advanced audio properties. What do you think?
Actually, wait, @Lange -- what do you think? Do you think it should be busses or do you think it should just be a device selection per source? I ask because maybe you might have a situation where you want to change the device for a number of sources without having to change it for each individual source, but I'm not 100% sure if that would matter for you.
So maybe busses would be useful in that sort of case, hm. Because what happens if you remove a device for example? On one hand it feels unnecessary, but I guess I can understand the potential need for it. Hm.
My gut feeling is that it should be busses. Not only does it add the useful abstraction you mentioned, but the program could also let a user assign an audio source to multiple busses, letting it go to multiple output devices. However, I'm very aware that this gets very complicated very quickly, and rapidly starts to emulate the features of a full-on digital mixer such as the Behringer X32. It may be worth studying prior art here of how digital mixers handle bussing, and how they present it in their UIs. Many of these digital mixers have desktop applications for remote controlling them, and we can study them to learn what things to emulate and what things to improve.
A good place to start is X32-Edit, which is the desktop UI for interfacting with the Behringer X32 digital mixer. You can run this program and tinker with it without actually needing to have an X32 plugged in: https://www.behringer.com/Categories/Behringer/Mixers/Apps/X32-EDIT/p/P0AWF
(the Behringer site is normally slow, but it seems practically unresponsive at the moment. You may need to try downloading X32-Edit at a later time)
Should there be a checkbox in advanced settings to enable the buses, so it doesn't make the UI more complicated for new users?
I believe a separate UI for busses is needed, and it's already there, the advanced audio window.
From a user experience and expectation perspective, going into advanced settings to turn on monitoring is counter intuitive. I would expect a toggle (with maybe a headphone 🎧 icon to clarify) on each source to listen to it. Thus a toggle on the mixer itself would make a lot of sense.
The busses would be at home in the advanced window. A split UI with busses on the right with drop down menus on the bus buttons to select a destination on the right (think voicemeeter). And toggles for the busses on the left side, below each source sounds like a very simple way to do it.
I might be missing a lot of nuance of course :)
Also, as I'm an audio newbie, would something like this call for a need for some sort of sync engine that adds some latency to the whole of OBS outputs (including virtual camera's) to sync everything up?
This RFC as presented appears to be a little too limited in scope and what it would allow as final end result. I would like to put together some kind of user survey and push it out to solicit feedback on where the weaknesses are with OBS and what people are actually trying to accomplish, rather than trying to fix the issues with (what feels like) the loudest users.
To simply add here, I really like that the Audio Dock in vMix allows one to easily toggle audio busses, which has been really useful for me in a church setup where we use vMix. We set bus A to speakers, bus B to virtual cable (for Zoom). It also makes it easier to figure out the audio routing for each source. For reference, (afaik) vMix always have the bus A and B buttons available, even if they are not configured in Settings > Audio. I believe that has an advantage, as one could easily disable a bus, and re-enable it later, without having to toggle that bus on each source. It also makes sense as you would not always have those bus devices connected. However, as it can be a clutter, I think it is fine that only configured busses are shown, as long as sources that used to have that bus on will still have it on by the time the bus is reconfigured.
Note that the Master bus on vMix is essentially the main bus (it points to a monitoring device), and is literally the same as the other busses (as you could configure a recording to use a different audio bus). And the headphones feature is literally another bus, except you could configure a source to output a lower volume to the headphones (compared to setting the overall volume of a bus). If we implement the Master bus feature, we would not need to have "Monitor and Output" and the rest of the options, which would be very confusing when there are multiple busses. It would simple be toggle this and that audio bus. I don't think the headphones needs its separate icon, but I see the potential advantage of having different volume of a source on the headphones (if we aren't going to support per-bus volume for each source).
If we are to support per-bus volume for each source (vMix does not, and I personally don't think it is necessary as it adds complexity that is niche imo, but might be necessary for some, though Audio Monitor plugin already fills that gap), I suggest having a window/dock where we select the source, and the right will have audio sliders for each bus.
However, I do believe it is necessary to have audio meters and volume sliders for each bus, if they are configured, in a different window. Perhaps we could have it as another dock, so it is opt-in. This would let users easily mute, change volume, etc. of the bus. Also allows adding audio filters to it before being sent out to the devices, which would be very useful, like being able to add a gain/compressor filter to only one bus. In addition, one could mix multiple audio sources to one bus rather than a virtual cable, for sidechain compression on those sources.
See https://www.vmix.com/help26/Mixer.html
Being able to separately toggle the busses means you can do a setup like this: If you are in two Zoom meetings, you can capture the participants audio in Zoom 1, send it out to bus B, which will be used as a mic for Zoom 2. Then participants audio in Zoom 2 -> Bus C -> Zoom 1 mic. This way there won't be echo. In addition, you can send out audio of videos playing in OBS out to both Zoom meetings. And all three audio sources will be in the recording.
In the future, we should implement audio mixes just like video mixes, so monitoring would be an output plugin instead of living in libobs. I just feel like that is the correct way forward. Since that is different than this RFC, I'll close this.