Latency audio should not be there

[HipHead]

Hello,

I'm using a FW audio card (about $250, Saffire PRO24 DSP). When i monitor trough the device software, that is called Saffire MixControl there is almost no lag or latency, i'm using 64 buffer size, but when i go to OBS the latency is very noticeable, to the point that my speech is being affected. I'm just using a noise filter, noise gate and compressor. On DAW software like protools i don't have any latency, i have to add many resource-expensive plugins so i can notice the latency, but even in that case is so low that my speech is almost not affected.
Is there any way to use the soundcard software to monitor OBS and it's effects and bypass the OBS monitoring system which doesn't work well for me? I've tried the ASIO Input capture plugin on OBS, without any luck.
Many people recommends to monitor OUTSIDE OBS but that's a big mistake, so please don't do that. You're not monitoring the real output and you can't listen if a viewer redeems a voice effect for example, and that limits a lot of the usage and experience, cause you won't notice that your voice is being changed and you won't react to that. Any way to reduce the latency or explain me a solution? Also why does OBS increases latency randomly? For example, if i'm using OBS, when open-closing settings or filter windows, to causes a lag to the CPU. I think OBS is using de CPU for sound processing, but i have a dedicated audio card, why doesn't it just take the exclusive control on it and uses it instead stealing CPU cycles? Something must be bad. Using OBS 29.0.2 updated with "low latency audio buffer" on the "audio" settings. That seems to improove the experience, but still having random lags. Also i would like some recommendations on VST plugins that change voice BUT doesn't add many latency as it wouldn't need many samples. Some voice changer adds more latency than others and its a bit annoying.

 

[HipHead]

Ok so here is an idea:
If obs had the ability to monitor some effects and not others, I mean. if you have an audio process that increases your latency, for example, a noise suppressor, since it needs several milliseconds to process the audio, having the monitoring open, the audio is delayed and this causes "lag" in my mind and for therefore it affects my speech. However, a noise gate does not need as many samples to process the audio. so the effect that causes latency in the user's audio monitoring remains muted and this silence only affects said monitoring, not the output, so this process should be done AFTER the sound is played trough monitors. something like PML (pre-monitor level/listen) and AML (after-monitor level/listen)

 

[AaronD]

Sounds like you probably do need a DAW, and for OBS to receive the finished soundtrack with no changes needed.

Yes, that's "monitoring outside of OBS", and so a problem with OBS or some processing that it does, will change the sound and you won't hear that. But that's part of the purpose of giving OBS a *finished* soundtrack so that OBS does *nothing* to it. No effects, no additions, *nothing*. Dumb passthrough. One global audio source that comes from the DAW, and that's it. *All* of your individual sources - mic, voice effects, etc. - are in the DAW, and OBS *only* receives the final product. The monitoring question then becomes the DAW's responsibility as well, and it's much better suited for that too.

Also i would like some recommendations on VST plugins that change voice BUT doesn't add many latency as it wouldn't need many samples. Some voice changer adds more latency than others and its a bit annoying.

Sounds like you need to set up *all* of them in the DAW, simultaneously in parallel, turn latency compensation on (adds extra delay to the fast ones so that everything lines up), so that the control is simply to mute/unmute the various FX returns.
Little different at this point from an analog FX rack, where everything is running all the time, and you simply allow a signal to pass or not.

Ok so here is an idea:
If obs had the ability to monitor some effects and not others, I mean. if you have an audio process that increases your latency, for example, a noise suppressor, since it needs several milliseconds to process the audio, having the monitoring open, the audio is delayed and this causes "lag" in my mind and for therefore it affects my speech. However, a noise gate does not need as many samples to process the audio. so the effect that causes latency in the user's audio monitoring remains muted and this silence only affects said monitoring, not the output, so this process should be done AFTER the sound is played trough monitors. something like PML (pre-monitor level/listen) and AML (after-monitor level/listen)

Does this effectively require a separate parallel path from the raw input to each destination? The signal chain builds on itself, so if you have an early thing enabled in one destination and not in another, then you must have a separate parallel path from that point on, with everything duplicated. This is functionally no different from monitoring outside of OBS.

If you really have a problem with just a handful of milliseconds, then you're REALLY sensitive. It would also mean that you have a problem with a live PA, because the speed of sound in air is roughly 1 foot per millisecond, or 3ms per meter. (reasonability check)

 

[HipHead]

Sounds like you probably do need a DAW, and for OBS to receive the finished soundtrack with no changes needed.

Yes, that's "monitoring outside of OBS", and so a problem with OBS or some processing that it does, will change the sound and you won't hear that. But that's part of the purpose of giving OBS a *finished* soundtrack so that OBS does *nothing* to it. No effects, no additions, *nothing*. Dumb passthrough. One global audio source that comes from the DAW, and that's it. *All* of your individual sources - mic, voice effects, etc. - are in the DAW, and OBS *only* receives the final product. The monitoring question then becomes the DAW's responsibility as well, and it's much better suited for that too.


Sounds like you need to set up *all* of them in the DAW, simultaneously in parallel, turn latency compensation on (adds extra delay to the fast ones so that everything lines up), so that the control is simply to mute/unmute the various FX returns.
Little different at this point from an analog FX rack, where everything is running all the time, and you simply allow a signal to pass or not.


Does this effectively require a separate parallel path from the raw input to each destination? The signal chain builds on itself, so if you have an early thing enabled in one destination and not in another, then you must have a separate parallel path from that point on, with everything duplicated. This is functionally no different from monitoring outside of OBS.

If you really have a problem with just a handful of milliseconds, then you're REALLY sensitive. It would also mean that you have a problem with a live PA, because the speed of sound in air is roughly 1 foot per millisecond, or 3ms per meter. (reasonability check)

The question is if using a daw while gaming and using OBS seems like it's going to be incredibly heavy on the computer, and this is just to be able to monitor my own voice through OBS without lag!
Also keep in mind that the sound effects must be activated through OBS because the configuration requires it, otherwise it would be really difficult to reconfigure everything through an external DAW. I've also found a python script that turns audio monitoring on and off at intervals of time, sometimes resulting in reduced latency. however, when using the computer with a game that has high CPU usage, it's going to spikes un CPU, and I honestly doubt that using a DAW is going to fix the problem in this particular scenario. However, if my stream was focused on the creation of live music, I think the solution is optimal. The question is why should the CPU process audio when I have an external audio card? Just as I have a dedicated GPU and the processor GPU has absolutely no use, however when that happens in a DAW it results in random clicks and noise. Also to add more problems to the problem, the driver of the sound card that I have been using for years has not been updated, and I don't know if it is convenient for me to use the ASIO drivers or any of the complements that exist for OBS created to use ASIO drivers and thus achieving monitoring without lag.
When I monitor my sound card through the software, there is no lag at any time, no matter the CPU usage.
I think this may be a clue

 

[AaronD]

@HipHead Did you delete your comment? I got the usual e-mail with the full text, but I don't see it here.

Anyway, I think there are two things to address there:

1. A sound card does not have arbitrary processing like a video card does. It's a dumb passthrough except for whatever gimmicks the manufacturers gave it to attract consumers. The CPU figures out what it should output, and gives the finished result to the hardware to make it happen.
2. Low-latency *does* increase CPU usage, even though it's processing the same number of samples per second. The reason is multitasking.
   • If it's doing nothing else, then it could sit around waiting for the next sample to come in, process it, and send it out. Practically no latency at all. But it can't do anything else either. 100% CPU, just for that.
   • If it's allowed to do something else while the hardware fills a buffer, then switch contexts to process that buffer and give it to the appropriate destination, then switch contexts again to do something else while the hardware plays out the buffer, then the "something else" can happen too.
     The context switch itself takes time, so the smaller the buffer, the more context switches you have, and the higher the CPU load. Buffer size is also latency, so there's a tradeoff to make.

 

[HipHead]

@HipHead Did you delete your comment? I got the usual e-mail with the full text, but I don't see it here.

Anyway, I think there are two things to address there:

1. A sound card does not have arbitrary processing like a video card does. It's a dumb passthrough except for whatever gimmicks the manufacturers gave it to attract consumers. The CPU figures out what it should output, and gives the finished result to the hardware to make it happen.
2. Low-latency *does* increase CPU usage, even though it's processing the same number of samples per second. The reason is multitasking.
   • If it's doing nothing else, then it could sit around waiting for the next sample to come in, process it, and send it out. Practically no latency at all. But it can't do anything else either. 100% CPU, just for that.
   • If it's allowed to do something else while the hardware fills a buffer, then switch contexts to process that buffer and give it to the appropriate destination, then switch contexts again to do something else while the hardware plays out the buffer, then the "something else" can happen too.
     The context switch itself takes time, so the smaller the buffer, the more context switches you have, and the higher the CPU load. Buffer size is also latency, so there's a tradeoff to make.

Sorry for late response and thanks for the explanation.

I found that a good way to avoid this is, to disable the desktop audio output, so you can control which outputs are monitored. It leads to higher setup complexity, and you have to setup the scenes before and add audio captures from the aplications, so in each scene you will have to add an audio source. Found that this causes a problem with the sound using this method. The sound coming from the app suffers a random lag, and after searching, found that its issue was years ago too:

OBS choppy / stuttering audio at random points in stream

Hi all, I've been suffering with this issue for a while now and I haven't been able to get to the bottom of it. Before I start my stream I do a recording test to make sure that the issue isn't occurring before I start streaming. Then, seaming at a random point in the stream, all audio starts to...

obsproject.com

The problem is the same: In random points of the stream, you get stuttering on audio for a few seconds, or even a minute or two, but that stuttering is only coming from the aplication (which is the aplication audio capture source, it's in BETA state.

Also i got another question. If i buy an external mixer and i connect it on USB, would i have the same latency problems that i've explained in the first post? If so, what would be the best idea to avoid the latency? What about a secondary computer dedicated on streaming?

 

[AaronD]

@HipHead As before, I got the e-mail, but the comment doesn't appear here. Weird.

You say you're using the Application Capture. That's known to cause problems, as you pointed out. Try to not use it, but have a zoo of loopbacks instead, if you really need that much. Each application that you need to keep separate, goes to a separate virtual speaker, which then appears in its own virtual mic, that OBS can pick up like any other mic.

Up to 5 separate loopbacks here, if you install the one at the top and both pairs further down the page:

VB-Audio Virtual Apps

VB-Audio Virtual Cable and App's

vb-audio.com

Add a small mixer between up to 3 virtual speaker(s) and virtual mic(s), which are separate still from the 5 above:

VB-Audio VoiceMeeter

VoiceMeeter Virtual Audio Device Mixer by V.Burel

vb-audio.com

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

Also i got another question. If i but an external mixer and i connect it on USB, would i have the same latency problems that i've explained in the first post? If so, what would be the best idea to avoid the latency? What about a secondary computer dedicated on streaming?

For one of my rigs, I have an external digital mixer (Behringer X32), that sends a completely finished mix (mastered too - it really is *done*) to a pair of RCA jacks, which then goes to the RCA line input of a USB sound card (Behringer UCA202). The mastering part is to make it *exactly* full-scale, as the USB line input sees it, regardless of what's actually happening, per the expectations of most viewers. (that's a bit less than full-scale on the board, because of the mismatch between pro line level from the board and consumer line level that the sound card wants)

For another rig, I have everything coming directly into the computer, and I use a DAW to do that. Digital Audio Workstation, essentially a complete sound studio in one app. As before, send the completely finished result to OBS to pass through unchanged (loopback), and that's the only input that OBS has.

Both of those rigs are Linux, by the way. Latest long-term-support (LTS) version of Ubuntu Studio. MUCH more sensible for audio than Windoze is! In fact, Windoze is so bad at it that an entire class of driver - ASIO - was invented specifically to bypass its stupidity and connect the app directly to the hardware. Neither Mac nor Linux needs that.

If you must have your game on Windoze, then a separate PC to capture its hardware output and stream it does seem attractive to me. HDMI out from the gaming PC (and that's all it does: just the game), to an HDMI splitter, to the gaming monitor and an internal capture card in the second PC. That HDMI run carries both picture and sound, so you shouldn't need any other wires between them.

• If you want your speakers or headphones to have that audio, then you can put an HDMI audio extractor anywhere in that path.
• If you want your mic to go to both places, then you could have a splitter too, or two mics. The two mics might actually be easier, since each system can manage them completely independently without messing up the other. If you've noticed the pile of mics on a political podium, that's probably why: each broadcasting organization has its own, and they don't touch each other.
• If you want to do much fancier than that, then yes, you can figure out what all you actually need to do, and find a physical audio console that does that: number and type of inputs, number of aux sends, built-in processing, etc.

For latency, it's still not guaranteed. My rigs are fast enough - I have to delay the audio on purpose, to line up with the camera(s) - but that doesn't necessarily mean that yours will. Especially, IMO, if you use Winblows for the streaming PC. If you build one from scratch anyway, to use for that, then I'd take a serious look at Ubuntu Studio, and the Linux side of the forums here.

Ubuntu Studio – A free and open operating system for creative people.

ubuntustudio.org