obs-studio
obs-studio copied to clipboard
obsproject
Audio Monitoring Buffer Buildup / Offsync
Operating System Info
Windows 10
Other OS
No response
OBS Studio Version
26.1.1
OBS Studio Version (Other)
No response
OBS Studio Log URL
OBS Studio Crash Log URL
No response
Expected Behavior
When monitoring audio, the monitoring audio buffer should be rebuild in case of buildup to avoid losing sync with the stream/recording audio buffer. It can be done either by evaluating the size of the buffer, comparing it to the bitrate to check if it is too long, or by continually rebuilding the buffer every X seconds.
Current Behavior
When monitoring the audio, only the monitoring audio gets off sync over time, while the streaming / recording audio stays in sync.
Steps to Reproduce
- On OBS, add an Microphone as an Input Source.
- On the "Edit" menu, select the option "Advanced Audio Properties".
- Find the microphone on the list and on the "Audio Monitoring" column, select "Monitor and Output".
- Let OBS run for a while. Over time the monitoring of the audio will get off sync with the input, making really hard to speak while monitoring the audio.
Anything else we should know?
To check the buffer buildup hypothesis:
To clean the buffer, you can click on the Eye Icon to disable the microphone, and click again to re-enable it, but will eventually rebuild the delay.
To automatically and continuously clean the buffer, you can use 2 "Move Source" filters on the scene: Move Source # 1: To disable the microphone source, wait an interval with it disabled (I got good results disabling for 100ms), and at the end enable the Move Souce # 2. Move Source # 2: To enable the microphone source, wait an interval with it enabled (I got good results with 60000ms / 1 minute), and at the end enable the Move Source # 1.
Please launch OBS with the --verbose flag and after reproducing the issue, post a log (Help -> Log Files -> Upload Current Log File).
Additionally, please test with 27.0.0-rc2 in case it was fixed by some of the audio fixes there.
Additionally, in future do not delete parts of the issue template. They are required fields for a reason (they help with reproduction & verification).
As @WizardCM said, please do not delete parts of the issue template. I've manually added the removed portions back in, but in the future we will close issues where parts of the template have been removed.
Please launch OBS with the
--verboseflag and after reproducing the issue, post a log (Help -> Log Files -> Upload Current Log File).
Log included in the main post. When I closed the program the delay between the input and the monitoring of the same input was about 500ms.
Additionally, please test with 27.0.0-rc2 in case it was fixed by some of the audio fixes there.
I tried with OBS 27.0.0-rc2, but the same thing happens.
Additionally, in future do not delete parts of the issue template. They are required fields for a reason (they help with reproduction & verification).
Sorry, I thought it was not relevant, but my assumption was probably wrong.
I'm slightly concerned about the suggested workaround. It seems to me that it would affect not only the monitor, which is where the problem is, but also the stream and recording, which are perfectly okay as they are.
I see no need to introduce an artificial hiccup in the audience's feed, to fix a problem that only exists in the producer's verification.
An alternate workaround is to wait for the problem to manifest itself, and then change the monitoring device. This resets only the monitor's buffer, while leaving the stream and recording unaffected. Change the setting back, of course, to hear it again, or physically switch your headphones or studio monitors to the other device. Either way, the latency is back to nominal...for a while, and then you change the setting again to reset again, ad infinitum. Unfortunately, I don't see a way to automate this, so you have to just bear with it until you get a break in your workload, and then do it manually.
See also Issue #3664.
@AaronD-GH If I understand correctly, the render and monitoring audio buffers are distinct (hence why the render audio is synced, while the monitoring isn't). If that is the case, a proper fix can be done by either by evaluating the size of the buffer, comparing it to the bitrate to check if it is too long, or by continually rebuilding the monitoring buffer every X seconds.
The workaround I mentioned (automatically blinking the audio source using Move Source) was mentioned just to verify the sync problem being fixed, not as a proper fix. A proper fix should change only the monitoring, not the sound source, as you mentioned.
About the workaround you suggested, I believe it would be possible using the webhook plugin and a script to change the monitoring state every once in a while, I'll investigate it further.
It took me some time since I don't code in Python, but here is a Python OBS script that enables and disables the monitoring of a audio input source after a set interval. This way it won't affect the streaming or recording, only the monitoring (it is barely noticeable, tho).
It is still a workaround, but a better one.
Since it's an OBS script you need Python 3.6 to run, newer versions may not work. I'll try to port it to LUA to increase the compatibility.
I am using OBS only for it's monitoring (not streaming at all) and don't need any fancy features, so do any of you know a older version where this issue (audio drifting gradually out-of-sync) does not exist?
I got around this issue by turning OBS monitoring off and using this "monitor filter" instead https://github.com/exeldro/obs-audio-monitor (version 0.8.0 of plugin, version 27.2.4 of OBS, win-x64)
I am seeing this bug or a separate instance of this in windows as well. OBS version 28.0.1 64 bit Capturing audio from EZcast CatchU and Avermedia's Live Gamer both UV meters show the right sound input, and the recording of both separate tracks look quite similar, however the monitored audio that goes out to the card becomes delayed every passing second. It does sound crackly and a bit out of range but that is not the focus of this thread, the focus is the fact that it keeps delaying.
I will check if the obs-audio-monitor plug in is updated to this version of obs :(
I ultimately opted to forego the audio monitoring entirely as I don't really need to have a duplicate audio source for my setup, just mirroring the screen is fine. IIRC the setup using audio-monitor plugin didn't work perfectly either, the delay was much less but ultimately it started to eventually drift too.
Based on your comment what I will do is patch the audio source in one of the Virtual inputs of Voicemeeter Potato and route it to my headset. Annoying but at least it has no delay. I do still get popping and crackling from the audio source but that is another report not this one. thanks @anzz1 for the update.
During the past months I have researched a lot around audio delay issues in OBS. I am coming from a different direction, my issues were mostly related to NDI feed audio desyncs and around audio delay issues more in general but that always also touched audio monitoring problems. Also for me it was never a problem that audio slowly drifted into becoming desync, instead it was triggered by an event like a short lag in OBS. Still, here's what I found, maybe it's helpful to someone here or sparks ideas for other solutions.
Make the sample rates of all audio sources in OBS match
That's the obvious one, I believe also the OBS log analyzer detects and warns about this, yet it's still too often overlooked even by people that actually know about this when sneaky things happen like you update your audio drivers and that silently resets your carefully adjusted sample rate settings without you ever noticing. I've even seen it happen that just plugging an USB audio device into a different USB port reset this. No matter whether you're an OBS beginner or pro, it's always worth double checking.
Every single source in OBS that has audio should match the same rate setting that is configured in OBS (Settings -> Audio):
If you set 48 KHz there, then all your audio devices in your operating system also need to be set to 48 KHz (= 48000 Hz). E.g. from the log that was posted in this original issue:
11:03:34.651: audio settings reset:
11:03:34.651: samples per sec: 48000
11:03:36.396: WASAPI: Device 'Mic Sony ECM 717 (High Definition Audio Device)' [44100 Hz] initialized
48000 Hz configured in OBS, this mic is set to 44100 Hz however. Probably not relevant here since this issue is about an audio output device (which according to the log is set to 48000) and there's also another mic set to 48000, maybe the one with the sample rate mismatch is not even used. I still thought it's a good example to show what log lines you should be looking for. If you configured OBS to 48000 Hz, search the logs for "44100" and make sure you don't find anything or only devices you don't use in OBS. Vice versa if you configured OBS to 44100 Hz. It's not sufficient to only check your sample rate settings in your OS settings, especially for capture cards it seems to be a common problem that e.g. in Windows an Elgato capture card is set to 48 KHz (which is also the correct setting for it) but from the logs you can see that OBS still initializes it as 44.1 KHz.
Ah, yeah, and also try to disable or enable device timestamps and see whether it helps (also mentioned a lot everywhere so you probably know that already, but just to be sure).
Use Asynchronous Audio Filter and Mute Filter
- Use the Asynchronous Audio Filter on all sources that are outputting audio that you actually want to use (usually at least the main desktop audio output). This filter actively corrects audio drift. With verbose logging enabled it can also give you detailed information about the audio drift currently occurring which can help with debugging any such problems, e.g. if you have sample rate mismatches as explained above this should become visible
- Use the Mute Filter on all sources that are outputting audio you don't want to use (e.g. webcams or other video capture devices).
Low latency mode aka Fixed audio buffering
Boy, is this whole part still confusing to me. The option is new since OBS 28 and for some reason located right where monitoring audio is configured, yet in my early tests the monitoring audio was the only thing enabling this did not fix, while it very well did fix A/V desyncs that occurred in the recording or a stream. Also the comments in the code don't say anything about this being specifically relevant only for audio monitoring. All the confusion aside, I assume when you're here you've already tried a lot of things and are quite desperate, might as well give that option a shot too now that it's there.
Avoid using render delay filters
Yeah, I know, a bit hard to avoid if you have a setup that just depends on them. but at least you might want to be aware that this could cause trouble and temporarily turn it off for the sake of testing and ruling it out. What I know for sure is that they break on lags, as demonstrated in #6673. And who knows, maybe they can also cause a slow desync over time.
I tried just using the Audio Monitor plugin, but it didn't solve it; ~However, using Asynchronous Audio Filter seems to have eliminated my issue of monitoring lagging over time. I'm about 60min into testing it. Thanks for the suggestion YorVeX~ Spoke too soon.
I tried just using the Audio Monitor plugin, but it didn't solve it; However, using Asynchronous Audio Filter seems to have eliminated my issue of monitoring lagging over time. I'm about 60min into testing it. Thanks for the suggestion YorVeX
I also tried the Audio Monitoring plugin when I read that it was suggested as a solution here but with the same result, it didn't improve the situation at all.
Spoke too soon, now, the next day, the delay is built up again even though I'm using the async audio filter. Darn it.
I'm reverting to the workaround I was using before, which is using streamer.bot timed action to turn my Audio Monitor filter off and on every few minutes.
@matijaerceg @YorVeX The only solution I found was disabling and enabling the monitoring to rebuild the buffer. I made a script that automates this, I hope this helps you. https://github.com/MarcusBuer/OBS-Anti-Mic-Monitoring-Desync
@matijaerceg @YorVeX The only solution I found was disabling and enabling the monitoring to rebuild the buffer. I made a script that automates this, I hope this helps you. https://github.com/MarcusBuer/OBS-Anti-Mic-Monitoring-Desync
Yes, I've seen that, thanks! It's good to have a workaround, but that shouldn't keep us from still searching for a proper solution.
It is important to separate two issues here:
- Possible sync/buffering issues with sources inside OBS (NDI was specifically affected by this)
- Audio monitoring not being in sync with the output of the sources
As for the second issue, there will probably no "fix" as our monitoring is "pre-fader" and as such not meant to monitor the output of sources, but the input.
Being able to monitor the actual output of a source ("post-fader") or being able to monitor and/or re-route OBS' master audio output to another app (virtual microphone, if you will) is a different feature and should be requested via the appropriate channels.
It's been a while now but @PatTheMav if I understood correctly, what you mean here with "not being in sync with the output" could mean that audio could get ahead of the video feed, or what? That the audio monitor is (should be) instant but the video stream encoding could make the video delay so that the feed not match the audio monitor.
In my case it was simply that the monitoring dragged behind the input ever-so slightly until it compounded to a long delay. IIRC after a hour or so it was already several seconds behind.
In even simpler terms, if I captured my desktop audio and clicked on something, the audio monitor would "hear" the click after several seconds. The output didn't matter, as this was also visible in the "sound EQ" or whatever which shows the volume levels.
I simply wanted to duplicate desktop screen and audio to a TV, since the refresh rate/resolution of the screen&TV didn't match so I couldn't just simply duplicate the desktop with Windows on it's own. I tried both using the "projector preview" window moved to the TV and setting audio monitor's output to the TV. And also making a typical combined video/audio stream of my desktop and then viewing this stream on TV. No dice, in both cases the video encoding worked exceptionally well with virtually imperceptible delay but the audio started to eventually drag behind.
Now I only use the "projector preview" function for video and for audio just set up app-specific outputs in the windows audio mixer instead, as I didn't really need to duplicate audio and it would havej ust been a convenience thing. It works perfectly this way. But if one needed to duplicate/stream audio too, they would be in trouble.
e: to be clear, I never had a problem with audio leading, only trailing behind.
I've never seen the audio lead in OBS, as is often the case when both video-processing and audio-processing the same live event. (It only takes a handful of frames ("video samples", if you will) to be noticeable, but it takes a few thousand audio samples to be noticeable. Thus, video delay is more of a problem than audio delay, and so the audio often arrives first unless it's compensated for.) But I haven't seen that in OBS. Maybe that compensation is already done internally, independent of any filter delays?
What I have seen, is a series of seemingly unprovoked audio hiccups in the monitor (headphones, probably, for most people), each of which adds an imperceptible amount of delay in the monitor, but after a few minutes the monitor audio is noticeably behind the video preview. (for audio, that's an absurdly large buffer...unless you actually want that much delay, in which case that's how you do it, but only on purpose) Changing the monitor device, or muting/unmuting the sources that feed the monitor, brings it back in sync. The stream is always in sync, as is the recording which shares the stream encoder, even while the monitor drifts out.
In my rig, I have an external audio mixer that feeds a USB line input, so that OBS is just a dumb passthrough for audio. This allows me to duplicate that source into three copies:
- A stereo version that goes to the stream, but not the monitor.
- A mono version that goes to the monitor, but not the stream.
- A stereo version that goes to the monitor, but not the stream.
I also have two hotkeys set up to simultaneously mute one and unmute the other of the monitored copies, so I can see if my mix works both ways. Doing that, also fixes the monitor delay, and the stream is always stereo, glitch-free, and in-sync. That works for me, but not everyone can afford an external mixer, nor is it justified for a lot of set-ups.
A better solution, even if nothing else can be done, would be to have an absolute maximum latency, and allow dropped samples instead. There might be a few hiccups. Oh well. At least it stays in sync!
Also (this might be better as a separate issue), I would love to be able to send a complete copy of the main output - video, audio, everything - to an HDMI port. So in addition to streaming to the internet with a few seconds of server delay, I could also feed an overflow room with a complete A/V rig of its own, and have it match the speed of sound as it "leaks" from the main room. A full-screen projector only does half of that: no audio, unless I send the monitor to that port at the expense of my headphones, and the monitor has problems as described in this issue.
I'm certainly not versed on how the audio IO / devices actually works but I suspect there must be some input buffer which is then played by the audio devices?
As it definitely looks like a buffer issue, specifically something like this:
A input buffer is filled with audio data at a rate of 1.0X b/sec, then the audio output device reads this buffer and plays the sound at matching rate 1.0X b/sec. OBS taps into the same input buffer, but outputs it at a rate of 0.99X b/sec. This would otherwise result in a perception of lower-pitched sound, but the deviation is small enough to be imperceptible to not hear the pitch difference but enough for the audio to eventually start lagging behind? So the buffer isn't being cleared at the same rate it's being input to.
As I never experienced any other artifacts like popping or whatever which could be heard as a result of the buffer catching up and it wasn't random in any way but rather very consistently lagged more and more, it seems that the buffer playback simply never caught up with the input.
I just noticed that this is tagged for Windows. My observation is entirely on Linux. So that can be added too.
As the name implies, "monitoring" is not meant to be used as an output - its main purpose is to give you a means of checking the input signal of a source before any processing is done. The main use case is recording or streaming and listening in to your own microphone input to manage the sound/texture/volume of your voice.
For that purpose, the monitoring output needs to be in sync with the input device (because listening to your own voice with even a few ms added will throw you off). Syncing its output with the main program output (as visible on the projectors) would defeat that entire purpose.
We do not have a master output option right now (and also no way to route this output to a different device), so for all intents and purposes OBS does not support an audio output that would be in sync with program output. If you use monitoring in that way, you have to accept the possibility of audio and video not being in sync, because it's not supposed to be.
As this is a fair ask however, we encourage you to either open a new (or upvote an existing) feature request for a master output that could be re-routed to a different output device and is in sync with the main output.
@PatTheMav Your reasoning doesn't make sense to me. Unless I'm missing something?
The main use case is recording or streaming and listening in to your own microphone input to manage the sound/texture/volume of your voice.
For that purpose, the monitoring output needs to be in sync with the input device (because listening to your own voice with even a few ms added will throw you off).
But if the monitor is tapping off of the raw input (pre-everything), and the output (post-everything) is in sync, then the monitor must also stay in sync. But it doesn't. The monitor lags farther and farther behind as time goes on, thus violating the very principle that you said was critical. (and I quoted here)
We still have a problem here. The monitor must have its own separate buffer, which is fine, but the problem is that it grows into something ridiculous, when it should stay small.
@AaronD-GH You are absolutely right, I got confused between the different issue reports in this issue and others - what I wrote applies to reports about projector video being behind monitoring output only.
Monitoring audio being behind projector video is indeed bad for monitoring purposes, thus I reopened the issue.
I was also able to reproduce the issue quickly with a video source from a network drive - after a few minutes more and more audio delay was added until finally the reported "hiccup" happened and monitoring was actually behind the projector output which should be in sync with the audio buffer.
I'm sorry that on my part I failed to adequately explain my point, and introducing my use case just threw the main point off. As the problem isn't audio monitoring being off-sync to the video stream, but off-sync to the real world. You don't have to have a video stream at all.
Basically what I'm saying, and what you're saying too is that the monitoring, as name implies, goes like this: (Input) Output Device -> OBS Audio Monitor -> (Output) Output Device.
And thus, it should be: Input == Output
But in reality: Input != Output. The 2nd output falls behind the 1st.
@anzz1 There's always some delay, when dealing with digital systems. It's not speed-of-light like analog is. Always a buffer, always some latency. The question then becomes, "How much non-zero latency can you tolerate?"
- It's (relatively) easy to delay everything so that all of the outputs match. This issue is about one of those delays drifting behind the rest.
- It's also possible (though difficult with video because of the low sample rate) to reduce the latency below a threshold where you notice, but it's still there and measurable. That's not what this issue is about.
- It's not possible at all to process everything instantaneously, so that a high-speed camera that can see both a full-screen projector and a direct view of the stage, sees them line up. They won't. Ever.
@AaronD-GH let's not get confused. It is ok if it has a delay, a latency, a processing delay. What is not ok is that a monitor input that should not be processed in anyway has an ever increasing delay that is not caused by the input - we know this because if it were caused by the input everything would be out of sync, recording including, but recording is perfectly in sync, only monitor keeps getting delayed every tick until it crashes.
What anzz1 is saying is not that the input is just unlike the output by a static and stable amount of time which would be normal and acceptable. What the user is referring to is the fact that this delay starts at close to 0ms and keeps increasing over time. Some times I have seen this delaying over 50s. It starts at 0ms and goes past 50s over time. No audible clicks, cracks, hiss or pops, nothing.
@matijaerceg I will say it again in the same units for clarity: it starts at close to 0ms and I have seen it go north of 50000ms