Bypass Windows Volume Level in Capture

[PHI]

Users of OBS seem to have one of two different experiences with the capture of "Desktop Audio:" either the audio is captured at full volume (or with the gain reduction set in OBS) regardless of the user's Windows volume settings, or the volume of the capture is reduced according to the volume settings in Windows. Whether a user gets one behavior or the other seems to depend on the audio device they're using.

Aside from the fact that this is a dramatic difference in the software's functionality between users, people in the latter camp have to deal with the fact that they can't control their own listening volume the normal way via Windows' volume setting without it affecting the volume of their captures, often resulting in dramatically lowered volume, unless they resort to cumbersome workarounds. Users in the former camp simply know the audio is captured at the baseline level it should be at without any reduction unless they explicitly apply one.

If we could have a way to bypass the Windows volume in capture for those for whom this is a problem it would be a massive usability improvement.

By the way I found many threads on google of people asking for help with this problem, even one thread from 2015. In my personal case, I recently went from using a device that didn't have this behavior to using one that does, and now suddenly dealing with this mess of a problem after everything worked so effortlessly before, truly painful!

 

[AaronD]

As you say, this is per-device. From my experience in trying to make a custom USB sound card, there is actually a mechanism for the computer to always send full-volume to the card, along with a volume setting, and have the *card* turn it down in whatever way it sees fit: digital attenuation before the DAC, analog attenuation after the DAC, limiter threshold, whatever. If they want to add some "loudness compensation" (bass and treble boost) at lower settings, they can do that too, etc.

I would imagine that the devices that expose that functionality are the ones that capture at full volume regardless, because that's the last that the computer actually knows; and the devices that don't expose that functionality are the ones that capture at reduced volume depending on the setting, because the computer has to apply that digital attenuation before sending it, and *that's* the last that the computer actually knows. The commonality is that what actually goes to the device itself is what gets captured.

In order to fix this problem, the capture point has to be changed, and that feels to me like an operating system thing more than an app thing.

---

For those of us that are used to professional rigs, and constantly harp on people who bring and plug in their own devices to turn themselves all the way up (yes, seriously!) so that our meters and controls end up somewhere sensible (We like strong signals! They keep noise away. *We'll* put you at a decent volume, you don't.); it's completely normal to keep all of our computers' controls at 100%, and use external hardware to control the volume.

There are USB sound cards with volume knobs on them, there are speakers with volume knobs on them, there are even headphones with volume knobs on them, there are inline volume controls that go between that and the computer, etc. We really don't consider that to be cumbersome at all; just part of a decent rig.
(And we don't get caught up in consumer marketing that says we *have* to have <this device>, which also happens to have no controls on it whatsoever because the company spent more on designing and marketing a specific use-case and an exclusive culture to go with it, than they did to actually make it useful.)

If you're wired, then it's possible to add a physical volume control that the computer doesn't know about.
If you're wireless, then you're taking a big risk anyway, for other reasons, that most pros are not willing to take. Wireless = random interference, quality drops, etc. Only use wireless if you absolutely have to, and then live with and work around its problems.

 

[PHI]

I actually use a Focusrite audio interface now, and it gives me this problem, which is to say that it reduces the volume of audio captured in OBS based on the Windows volume setting. Previously I used an older Presonus audio interface and that one did NOT have this problem in OBS, but it still respected the Windows volume level in its output to headphones. Using ASIO drivers though does completely bypass Windows' volume settings.

This is a tangential subject, but, while it is true that I personally could max out Windows volume and use the knobs on my interface to control my listening volume instead, I use the knob on my keyboard to control volume. And using Windows volume has the added benefit of letting me set the volume digitally to exact numbers that I'm used to. Almost ironically, setting the volume digitally like this has benefits for professional audio work too, since you can listen and compare things at exact volume levels and manage loudness issues that way.

In order to fix this problem, the capture point has to be changed, and that feels to me like an operating system thing more than an app thing.

That is the thing I would like to see nailed down. But I would be entirely welcoming of any hack solutions too. It's remarkable how much this one stupid detail affects the usability of the software.

 

[AaronD]

If you want to listen at an *exact* level, most professional digital mixing consoles should let you type a number too. But most people don't have one of those. :-)

It can be replaced though, with a DAW on the same machine that runs OBS, and can also be free, and then the problem becomes one of routing audio between apps. I do that on a couple of my rigs, with a dedicated output from the DAW to each destination, and it does accept a typed number. My powered speakers, then, are set for "equal headroom" and kept there, meaning that the amplifier clips at the same level as the sound card that drives it.

On Windows at least, there's also what you might call a "DAW Lite", that is essentially a "postage stamp" of a mixing console with a bunch of individual outputs, some of which connect to virtual sound cards to solve the routing problem too:

VB-Audio VoiceMeeter Banana

VoiceMeeter Banana, the Advanced Virtual Audio Mixer by V.Burel

vb-audio.com

VB-Audio VoiceMeeter Potato

VoiceMeeter Potato, the Ultimate Virtual Audio Mixer for Windows

vb-audio.com

 

[PHI]

Unfortunately VoiceMeeter seems to impart some additional latency to the audio, so it's not a solution I'm happy with.

 

[AaronD]

Unfortunately VoiceMeeter seems to impart some additional latency to the audio, so it's not a solution I'm happy with.

Yes, everything does, but if it's less than what OBS does with the video, it's fine, right? If you're that serious, then you probably also have OBS's Sync Delay set to line things up again, and so you just reduce that by whatever your audio chain takes.

The Sync Delay does go slightly negative too, which reduces the buffer below the default size, with the usual risks that go along with that. But if it works, it works.

 

[PHI]

Synchronizing the capture is one thing, but I don't want any extra latency on what I am hearing.

 

[AaronD]

I don't want any extra latency on what I am hearing.

Then you probably want that signal path to be purely analog, full stop.

Or, if you're okay with a small amount of unnoticeable latency, like about 1ms or so, then a standalone digital console can work, but that's still outside the PC.

If you must use the PC, then you have up to about 100ms of latency *just because you're on a PC*, regardless of what software or set of software you're using. That's because it's not dedicated to anything but is constantly jumping around from one task to another. So a real-time thing like audio has to record a fairly long buffer while the machine is doing something else, and then that buffer gets processed all at once, and then it plays back out while the machine is doing something else. You can't avoid that on a multitasking machine.

What you *can* do, if you have the tools to do it (the JACK audio system does on Linux; don't know about anything else), is to explicitly set the buffer to be as small as possible without causing xruns/errors. Chances are, that'll be small enough that you won't notice, but still more than what dedicated hardware would do.

If you're comparing to Windows' "listen to this device" setting, there's a chance that Windows doesn't actually see that audio at all. Most sound card chips (I've read the datasheets for a few) have a mechanism to send an input directly to an output, all inside the chip, and purely analog. So no latency there...and it's not a fair comparison to software if that's in fact what your machine is doing.

 

[PHI]

I appreciate what you're saying, but my only concern is capturing what's on my computer. VoiceMeeter with its virtual inputs and outputs appears to impart more latency than just using the standard drivers for my audio device. For me that's a dealbreaker.

Ultimately this thread is not about latency though but about volume levels, and how OBS interacts (inconsistently) with the sound drivers to said results. It may not be the fault of the OBS software but it's a problem nonetheless. The ideal here is that I can record what's on my screen and then when I play it back it will be the exact same volume. For me, before, it simply worked that way; now it does not, only because I changed my audio device.

 

[AaronD]

...how OBS interacts (inconsistently) with the sound drivers...

OBS is perfectly consistent here, and probably has no other option. It's only using what the operating system makes available.

For me, before, it simply worked that way; now it does not, only because I changed my audio device.

*That* is where the inconsistency is. It's in the physical audio device. Not OBS, not the OS, not even the driver, but in the physical device. Specifically, whether it takes full-volume regardless and attenuates in the device itself, or whether it makes the OS pre-attenuate.

The ideal here is that I can record what's on my screen and then when I play it back it will be the exact same volume.

Absolutely! It would be wonderful if every rig did that! Complain to the audio device manufacturers about something that very few people have a clue about. :-/
And if they're being honest and open, they'll probably refer you to the Chinese chip manufacturer(s) that they just buy from and use as-is. How's your Mandarin?

Until that gets some traction, you'll just have to deal with your PC volume being glued at 100% and controlling it elsewhere. Sorry.

Or you might complain to Microsoft, and see if you can get Windows' standard loopback to be pre-attenuation for the devices that need it. They at least speak English.
And while you're at it, maybe you can get it to be pre-everything, or have two for each output: one dead raw, and one post-ear-candy but pre-attenuation. But that's entirely on Microsoft, not us.
Right now, it's post-everything, which means that whatever consumer ear-candy you might have is also included...and applied twice when you record that and play it back...

 

[PHI]

*That* is where the inconsistency is. It's in the physical audio device. Not OBS, not the OS, not even the driver, but in the physical device.

Some people have reported that using the Windows option to "roll back" drivers to some previous version has solved this issue for them, so it would seem based on that that the drivers are the determining factor for this behavior.

It's not useful to concern ourselves with "whose fault it is" here. The reality is that the problem exists, it affects how OBS works, and if there's something that we can do to improve it then I believe we should try to.

 

[AaronD]

Some people have reported that using the Windows option to "roll back" drivers to some previous version has solved this issue for them, so it would seem based on that that the drivers are the determining factor for this behavior.

Sometimes. Any device can take pre-attenuated samples, along with a volume command of 100%. (or hardware-initialized to 100% and a driver never changes it) But if a device actually *needs* that, and doesn't have its own volume control at all, then shuffling drivers won't work.

It's not useful to concern ourselves with "whose fault it is" here. The reality is that the problem exists, it affects how OBS works, and if there's something that we can do to improve it then I believe we should try to.

Yes. I'm just explaining the ecosystem that surrounds it, which is and probably always will be the Wild West. For some physical devices, it's simply impossible to have the recording volume separate from the output volume, because of the combination of how they work and how the other software works that they interact with, which is written by a bunch of different people with a bunch of different mindsets that don't really talk to each other.

If Windows were different, it could be consistent regardless of device, but I understand why they did it that way, even if I don't agree with it. It's not so much about the usefulness, but about their ease of coding it. So of course it's annoying to use!
I would have done it better, as an audio engineer myself...or rather, I would have *spec'ed* it better, for someone else to write. You probably don't want me writing Windows operating system code!

---

So I come back to the old do-it-yourself mentality. If you want something that works well for your workflow, you need to understand for yourself how the tools actually work, and build the rig yourself using that detailed knowledge, to do what you personally want. That understanding, is really my goal with this thread.

• Need another loop through the system, because a tap point is in the wrong place and you can't move it? Oh well, I guess that's just what it takes. Or maybe you change hardware because it has a different order of things that works better for you.
  • That's also true for analog mixing consoles, and (among other things) whether their Insert jacks are pre- or post-EQ, or switchable (rare), or if they have both (also rare). That actually makes a pretty big difference if you use outboard processing like channel-compression, or if you use the Insert jacks to split a single mic into multiple independent channels (one for singing and one for speaking, for example, with only the cost of some wire, 2 plugs, and a bit of solder, and not another mic that the talent doesn't think to use anyway!). If you don't like the way your board is designed, get a different one. (maybe you can tell I've done that...)
• Does that extra loop cause too much latency? Maybe your audio system in general is too slow, and you need to rebuild the whole thing to be equivalent on a different platform, which has a faster audio system. Windows isn't the only player, by the way, and it's not really designed for media production anyway. Using it for that, is really more of a hack than a good design.
• Do you only know Windows and think you *have* to stick with that? Well, maybe it's time to broaden your horizons. :-)
  • Mac and Linux are both viable alternatives, with vastly different mindsets behind each of them. Use what works; don't be married to anything.
  • I personally use Ubuntu Studio Linux. It's easy enough to switch to from Windows (I did), it has a TON of media stuff preinstalled and working, including OBS, and it does seem to have a fast enough audio system to use live, even through the full-blown DAW that's preinstalled and working. (there are reports of people actually using that DAW on that system for actual live stage work, through a many-channel interface) Just learn the new toolset that comes with it, all for free, and go.
  • I would recommend though, to keep what you already have, as annoying as it might be, until your playing with the new one becomes confident enough to rely on. It probably won't be at first, and you really don't want to be forced to use something new all at once, right now!
    • If you have another machine, so you can run both at the same time, do that. Much easier to copy and compare that way, and no chance of messing up the old one.
    • If you only have the one machine, dual-boot it.
      • Or if you're paranoid about one system wrecking the other, get a second hard drive so you can physically swap drives, and keep the "sacred" one unplugged while you run the other. You might have to disable some of your BIOS's security before you do that, or it'll lock onto the freshly installed drive and refuse to run from the old one. That was not a fun discovery for me! Again, know your tools...

I wish I could say that there's an easy way to make any system do anything that is conceptually simple, like your initial request, but that just doesn't exist in the technical world. Concepts don't exist there, nor do complete systems. It's all a collection of tools, each of which does certain things in certain ways, and their designs are all over the place in terms of being easy-to-write / hard-to-use or vice-versa. Gather and put some together to collectively do what you want. If what you have doesn't, get something else.