Yup. I understand your pain. I have a similar issue with capturing one source while trying to view another. The source i capture must be full volume so if i for instance play a video at the same time, i have to hear both sources in full volume. If i "mute" the captured source, no sound is written in the resulting video. It would be great if there was a way to mute the captured source and hear everything else but also record in full volume in the final recorded video at the same time. I've tried all that on a laptop.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Bypass Windows Volume Level in Capture
- Thread starter PHI
- Start date
-
- Tags
- audio volume mixer
Yup. I understand your pain. I have a similar issue with capturing one source while trying to view another. The source i capture must be full volume so if i for instance play a video at the same time, i have to hear both sources in full volume. If i "mute" the captured source, no sound is written in the resulting video. It would be great if there was a way to mute the captured source and hear everything else but also record in full volume in the final recorded video at the same time. I've tried all that on a laptop.
Read the rest of this thread. I think I've been around this bush several times now....I have a similar issue...
TL;DR: OBS can't be made to work, even on the developers' end. It's an operating system problem, not OBS. Deal with it.
Most of my beating around the bush is to explain how to deal with it. Yes, it's messy and not straightforward, but there really is no clean solution.
In this economy? With current oil, electricity and RAM prices?What if you had two separate machines?
You are insane ! ;)
But seriously, not everyone has a professional studio, not everyone is looking to build one ...or need one. But let's put that aside...
Why would I do this? Why is this a better solution than mine?
Yes, it solves the problem of controlling the volume separately if you have multiple PCs (though then you don't really need Linux, but at least it's free). But it's a very inefficient solution. You need twice the hardware, a capture card, maybe a HDCP stripper too, twice the space, power, upkeep cost... Just to work around something that could be fixed with software and zero waste?
(The only thing this could do that my workaround can't is muting the game while still recording it.)
Yeah, if you can afford to dedicate a complete PC to a game then it might work, but I still prefer to capture application window rather then display, to prevent any potential information leak. (Obviously you wouldn't do your taxes on the gaming PC... nor on the streaming one, you would need on a 3rd PC ;) - but you would still need to disable any potential popup windows).
Regarding the "pre-fade" signal:
I had read your previous replies, that's why I mentioned that I don't think it's really a problem here. You didn't really explain what is in your professional opinion wrong with my solution (or rather workaround). How much quality degradation do you think it causes?
It's probably more important what codec, bit rate we use than this slight resolution loss. Do you have a suggestion on those? (Otherwise just optimizing one part - the signal path - of the system doesn't matter.)
I understand that theoretically it's better to capture raw 100%, and I would like to do that (and freely adjust game volume without changing the recording) but Windows doesn't let it (as my current understanding).
A 2 PC setup might allow this, but the cost benefit analysis just doesn't work out in my case.
Side note: If you have a "serious rig" then all problems... I mean this can seem like "if you have a hammer all problems look like nails" type of response. Or an uncharitable person might even say it looks like preaching instead of helping solve the problem. ;)
But I appreciate you taking the time writing professional advice - even if I think I won't be able to use this suggestion right now - hopefully it helps someone. <3
How serious are you? If it's just a hobby, then you can afford to have some things not work or be awkward or whatever. If you actually want something good and reliable, then you can afford to have some "inefficiency" to guarantee that it works....it's a very inefficient solution. You need twice the hardware, a capture card, maybe a HDCP stripper too, twice the space, power, upkeep cost...
(like triple entire-system redundancy in commercial aircraft, or 5x in the space shuttle: they're *REALLY* serious about reliability!)
If you're made of money, then that guarantee becomes easy: just buy a whole studio worth of dedicated gear and a crew to run it. For the rest of us, we need to actually know a few things, like:
- How to set up and manage a general-purpose computer to do what *we* want, which is not what the vast majority of a commercial one-size-fits-all product is bought to do and the company behind it knows that.
- Just like, "the nice thing about standards is that there are so many to choose from!", the nice thing about Linux is that there are so many pre-fab specialized distributions that you can almost pick one that already does most of what you want right out of the box. The one that someone else recommended to you for their own reasons might not work for you because of your own different reasons, but there's probably something else that does fit your use with only some minor tweaking to finish the last 10% or so...if you do your due diligence to actually learn what you're doing in the first place. Media production is inherently technical, with no real way to avoid that except to accept what someone else decided and just live with it.
- Keep it from borking itself when the AI overlords tell it to.
- How to find a dirt cheap HDCP stripper, if it's even needed.
- No-name Chinese [utility product], that uses the same dirt-cheap input chip as in a TV, which must decrypt both to make the TV work and to do this other function, and then the no-name Chinese thing just doesn't re-encrypt...
- Etc.
If you insist on fixing it with only software and no additional hardware, then the solution is a loopback or virtual sound card. And even that isn't entirely free from the operating system's quibbles. (and OBS's horribly outdated, misunderstood-to-start-with, and partially band-aided audio system not playing well with some loopbacks too) Again, know your gear...like ACTUALLY KNOW IT...so it becomes trivial to set it up in potentially odd ways according to everyone else, to make it do what *you* want.Just to work around something that could be fixed with software and zero waste?
Like I said, media production is inherently technical. If you want to create a good product smoothly, you have to wear that hat too.
Separation of duties. Yes, I completely agree with having a dedicated two-machine game-streaming rig that does nothing else ever, and a third one - possibly dirt-cheap almost-disposable - for everything else. Maybe even several of those if you're really concerned about privacy/security, but at some point it starts getting unwieldy.(Obviously you wouldn't do your taxes on the gaming PC... nor on the streaming one, you would need on a 3rd PC ;)
Like I started this post: How serious are you?
You're right about the analog version of that. Dropping the signal into the noise and bringing it back up, does amplify the noise. And if the digital version only used a handful of bits in integer format, then you could make the same argument there too. But pretty much all digital systems use at least 16-bit integer, and all serious digital mixers use at least 32-bit floating-point. The popular Behringer X32 and its X-Air "little brother" use 40-bit FP internally, despite the I/O converters "only" being 24-bit integer.Regarding the "pre-fade" signal:
I had read your previous replies, that's why I mentioned that I don't think it's really a problem here. You didn't really explain what is in your professional opinion wrong with my solution (or rather workaround). How much quality degradation do you think it causes?
It's probably more important what codec, bit rate we use than this slight resolution loss. Do you have a suggestion on those? (Otherwise just optimizing one part - the signal path - of the system doesn't matter.)
The reason to use so many bits is to keep the cumulative round-off error below what the output can see, and so it effectively becomes "perfect", analog-to-analog. And the 24-bit converters on a professional rig or even "prosumer", are far better than any analog circuit could ever hope to be. It's difficult, but possible, to make a useful analog circuit that outperforms a 16-bit conversion, but for 24-bit, not a chance! So there are several layers of cheap defense against any accusation of a digital system somehow being "non-ideal", and I'd expect even a token PC audio system to do something similar. 32-bit FP at the very least, or maybe 64-bit given that the "double" datatype seems to be the default for general-purpose FP in C/C++.
The key difference between integer and floating-point formats is that FP has astronomical headroom and a constant signal-to-quantization-noise ratio regardless of level, while integer has fixed headroom and noise like analog does. For a quick and easy utility DSP, it's fine to just tack a few extra bits on and keep it integer, but for complex work, FP is easily well worth another pair of conversions! And like I said, I'd be surprised to find a popular OS that didn't use FP for audio already. OBS does.
The one point I'd argue, is when the OS converts to what the physical sound card wants. If the card can take full-scale samples regardless, plus a volume setting, then that could be what it gets, and OBS might receive 100% volume all the time regardless of that setting. If the card does not have its own volume setting but must receive reduced samples, then you start losing resolution at the card's output, and OBS might receive that reduced volume too. What each card wants, is part of how it describes itself to the host, and so it's not guaranteed which way a random card is.
Then the question becomes, "Does the OS reduce the FP version and make that the loopback *before* converting to the card's format? Or does it do *all* of the conversion in one atomic step and convert it back again for the loopback?" For quality, the answer is obvious - keep it FP! - but if it's written by an intern who only saw the one formally-defined use-case and thought they could be efficient, and no bean-counter thought it was worth changing...
For comparison, I'd estimate a pure analog PA rig to be around 8- to 14-bit integer of actually-useful resolution, depending on a number of physical factors that don't all have to do with the quality of the gear itself. (I actually have one myself, inherited from several church upgrades and made into a quite capable rig on a cart, which is presently replacing a digital console at another church while they change some things around, and has some people wondering if the digital one could be made to sound that good...<shrug?>) Anyway, I say that to point out how good digital really is, if such a low-numbers-equivalent analog rig is already as good as that...
---
So for your workaround, as long as everything remains static, I think it's *probably* still okay after dropping the level and raising it back up again, all digital. Might be worth a test to see: play a lossless recording through it and record it to lossless again at the other end, and compare. (WAV or FLAC, for the two most common options)
But even if they're different, you still might not notice, especially if you didn't quite get the levels matched *exactly* and so the bit-perfection fails, but then an auto-gain of both recordings makes the difference so quiet that you have to gain *that* way up to hear it even by itself...
All of that said though, it sounds awfully brittle to me. Adjust your headphones, and OBS jumps around, for one obvious example. But you might also argue that that's actually a plus...so long as your perception and preferences stay *exactly* the same between sessions.
Like a Broadcast mix being post-fade from Front-of-House on the same console, so it intentionally inherits whatever adjustments the FoH Engineer makes, which are usually in response to the same things that the Broadcast needs to adjust for too. Still better to have a dedicated engineer for that mix, but post-fade removes about 50-90% of that workload, so the remaining 10-50% might be tacked onto a camera operator, for example. (that person's focus is mostly on audio during rehearsal, and only on cameras enough to see that they work and possibly to set up some shots and save those presets; and mostly on cameras while on-air, while continuing to monitor the audio and tweak it occasionally: how much of that you count, gives you most of that variable percentage)