Please allow for mono recording of Microphones - I'll explain why...

[Thebigcheese]

Actually, now that I think about it, having an Open Virtual Mixer would probably be the better way to go. Something like Wave Link, but like... Better, and not hardware dependent. If I knew anything about coding, I'd try to get that going. Subject for another thread, I suppose.

 

[AaronD]

...then it should have at least some basic mixer features.

...which it does already. Enough for someone that "just wants to" toss a mic up and stream their game. But much more than that is still clunky, even with all the additions since then. I don't think it should go beyond that one specific use-case. Fix the hardware-compatibility problems so that the Monitor stays useful, and that's it. Everything else needs an external tool.

Or:

Either that or someone should write a companion utility that handles all the audio but still allows you to feed it into OBS to encode each track into the video file like OBS does now and then OBS should remove the mixer entirely.

That's more along the lines of what I understood the devs to want, last time I crossed paths with them. OBS's native audio should be *dumber* than it is now, for easier maintenance on their end, and something else should handle anything more than just the absolute *very* basics.

Design OBS's audio primarily to interface with an external tool, with no processing whatsoever in OBS itself, and publish the API so that someone *else* can make that tool. By greatly dumbing down the audio functionality in OBS itself and replacing it with that API, maybe that'll put enough pressure on the community that a bunch of those companion utilities for audio will pop up, with varying complexity and functionality.

If they go that route, I think it would need:

• A separate output for each audio source that originates in OBS. Not mics or games - those connect directly to the external tool - but video soundtracks and camera audio that can't be separated until it's already in OBS. Send them straight out, independently, to the external tool, with no processing whatsoever in OBS. Just decode it and spit it straight out as-is, not mixed with anything else.
  • On Linux, OBS already has a JACK source and sink, that can be *almost* like this, but they're presently only available inside a scene. They can't be global. Then when you switch away from that scene, the JACK endpoint goes away and takes the connections with it. When you switch back to that scene, the endpoint is re-registered, but the connections *don't* come back. So that's useless.
  • Make the JACK connections global, so they never go away and lose their connections, and that might be a half-decent starting point for this idea here. Of course the direct copy/pasted code only works on Linux, but the high-level *concept* of what the user sees, might still apply to other systems that do things differently under the hood.
  • Again, no processing, just a bunch of direct outputs for an external tool to pick up: a separate one for each "noisy thing", that are always present and active so that their connections stick around, and kept silent (active stream of zeroes) unless their sources are shown.
• A separate input for each Track to record or stream. Again, no processing in OBS, and no cross-connections either. If you want something on multiple tracks, you need to set up the external tool to do that, not OBS itself.
• Probably no direct hardware connections. So no Monitor, in OBS proper, and no mic as mentioned before. Again, that's an "external tool" thing, and also moves the async problem over there so that OBS itself doesn't have to mess with it. Likewise for choosing specific channels of a many-channel interface: that's also an "external tool" thing.
• And probably a "backwards compatibility" type of external tool that ships alongside that version of OBS, so that existing rigs still "just work" the same way after upgrading to it. The old functionality would technically no longer be in OBS proper, but it does come along for the ride as the default audio utility, which is active by default so the old rigs don't break, and you can swap it easily for something else.
  • That might take some of the pressure *off* of the community to make a better one right away, but at least it doesn't completely wreck everything!
    • Like the Qt update did with no warning, between v27 and v28. Technically, it was needed - it went from a verion of Qt that was well out of date by that point to one that was still current - but it was not handled very well at all! Essentially, all of the plugins failed to load, which meant that their settings didn't load either, which meant that they weren't re-saved when OBS closed and overwrote the settings file. Now they're gone forever, *even after downgrading back to what it was*! *That* was the insidious part! And it wasn't warned at all!
  • The pressure will probably come back though, because the default "backwards compatibility" utility will essentially be a copypasta of the present mess, and never touched again. Let it rot, so that the rats jump ship. Set a date to delete it, and then the next new version after that date just doesn't have it.
    • If you upgrade all the way from now to that in one shot, then your rig will break, as should probably be expected for jumping that far at once. For a couple of releases both before and after the backwards compatibility mess goes away completely, keep a banner on the website or something similar, and perhaps cause the automatic updater to throw an error message, to warn of what's about to happen and then what did happen, and what it means for an upgrade across that boundary.

 

[AaronD]

Actually, now that I think about it, having an Open Virtual Mixer would probably be the better way to go. Something like Wave Link, but like... Better, and not hardware dependent. If I knew anything about coding, I'd try to get that going. Subject for another thread, I suppose.

Yeah, you're probably right. Enough hijacking this one. :-)