Open MechanicallyDev opened 3 years ago
WizardCM
commented
3 years ago 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).
RytoEX
commented
3 years ago 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.
MechanicallyDev
commented
3 years ago 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.
AaronD-GH
commented
3 years ago 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.
MechanicallyDev
commented
3 years ago @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.
MechanicallyDev
commented
3 years ago 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.
anzz1
commented
2 years ago 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?
anzz1
commented
2 years ago 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)
kryztoval
commented
2 years ago 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 :(
anzz1
commented
2 years ago 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.
kryztoval
commented
2 years ago 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.
YorVeX
commented
2 years ago 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.
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] initialized48000 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).
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.
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.
matijaerceg
commented
2 years ago 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.
YorVeX
commented
2 years ago 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.
matijaerceg
commented
2 years ago 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.
MarcusBuer
commented
2 years ago @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
YorVeX
commented
2 years ago @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.
PatTheMav
commented
1 year ago It is important to separate two issues here:
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.
anzz1
commented
1 year ago 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.
AaronD-GH
commented
1 year ago 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:
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.
anzz1
commented
1 year ago 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.
AaronD-GH
commented
1 year ago I just noticed that this is tagged for Windows. My observation is entirely on Linux. So that can be added too.
PatTheMav
commented
1 year ago 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.
AaronD-GH
commented
1 year ago @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.
PatTheMav
commented
1 year ago @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.
anzz1
commented
1 year ago 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.
AaronD-GH
commented
1 year ago @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?"
kryztoval
commented
1 year ago @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
commented
1 year ago It goes way past 50ms in my experience
EDIT: misread 50s as 50ms
kryztoval
commented
1 year ago @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
AaronD-GH
commented
1 year ago @kryztoval That is correct. I think what tripped me up was:
...off-sync to the real world. You don't have to have a video stream at all.
Given my interpretation of "real world" (see my last bullet point), this didn't really clarify:
...it should be: Input == Output
But in reality: Input != Output.
So I still thought that @anzz1 might have wanted the processing to be instant. Apologies for the confusion.
kryztoval
commented
1 year ago @AaronD-GH I totally understand, I was not saying you were missing the point intentionally, I was just trying to keep the discussion on track with the problem and trying to make it clearer because, as a long time support agent, sometimes at some point the discussion can take different paths and it needs to converge. :)
PipeL1n3
commented
1 year ago Hi, since months i am running into this problem but cant get it fixed, i also often looked out to the issue reports that are here to this topic, and as this one they are years old. Why isn't this fixed? Don´t we know where the problem is? Why is it this hard? Here i have log from last stream since i changed into scene with external video-feed (coming in by obs-teleport).
as you can see its relativly quick hitting "max latency" and alsways adding more buffer to the device. I don't exactly know what each of this line mean, but i am ending with a delay which is at least 3 seconds between source video (which i am watching at source systems Display) and audio monitoring (hearing over obs running on second PC). When i understand it right, it has in the middle a 960 ms delay on the source PLUS added 1441ms delay of monitor. For the Viewers Video and Audio always keep in sync (but might be getting more delayed in whole, but thats not the point). But for me watching original video, but hearing monitoring audio its getting more and more out of sync, as i said at least 3 seconds or more. This really is annoying. It was there on OBS 27, its still on OBS28. Over the year i changed system twice, but this error consists. I had the issue when using CentOS (pulseaudio based), i had it when trying ubuntu studio, i still have it with Almalinux (pipewire based). I even running a RT-patched Kernel now and its still there. I I had it when source was NDI, i had it when source was physical Capture Device, i still have it using OBS-Teleport. May have it too with local captures, but i am not playing video media on streaming-PC, so i can´t say if its running out of sync. As in log visible, i retoggled monitoring middle of the stream, this is fixing error for some time, but as you can see just 11 minutes later its hitting "max latency" again.
I would love to get this fixed, maybe do some testing if someone gives me a point to look for.
Greetings
anzz1
commented
1 year ago One thing worth trying might be to go back versions (to the time before reports started appearing) because maybe the bug didn't always exist and was introduced somewhere along the way.
dojima
commented
1 year ago I don't experience this problem when I set my capture device Audio Output Mode to Output desktop audio (DirectSound), rather than Capture audio only. I guess my question is, is there some technical reason why you can't combine capturing and outputting to desktop audio? I kind of already do this manually by outputting the system audio to a track. When capturing audio with this method, I do get about 67ms of latency, but that's tough to notice while monitoring and easily fixed with a sync offset or later in post for recordings. I suppose I could also workaround the issue by duplicating the capture device source and setting one to Capture audio only and the other to Output desktop audio (DirectSound). Since such an easy workaround is possible for video capture devices, why not streamline the solution?
Is there any reason why other devices can't directly output to desktop audio?
It would also be nice if you could choose the device for Output desktop audio; it seems to use whatever the default device is under Windows, but that would be a separate issue.
PipeL1n3
commented
1 year ago Is there any reason why other devices can't directly output to desktop audio?
It would also be nice if you could choose the device for
Output desktop audio; it seems to use whatever the default device is under Windows, but that would be a separate issue.
I am not sure i am understanding all of this, but as the problem is not OS-related, as it is there on both Windows and Linux (dunno about MacOS), doing some Windows-only related settings can't be the solution.
I recently have done some improvements and for now the delay kept in acceptable ranges. This helped me out for now:
I am now using two Plugins to keep things going: One is obs-async-audio-filter which add samples to audio if they mismatch, so there won't built up desyncing after time. I am >using it as filter on teleport-source on receiving OBS. https://github.com/norihiro/obs-async-audio-filter Then i am Using Python script for OBS which toggles monitoring on and off after time. I set it to ~2mins and let it toggle >monitoring of teleport-source. its avaible here https://github.com/MechanicallyDev/OBS-Anti-Mic-Monitoring-Desync Since i use this combo, i didn't encounter any desyncing problems.
Maybe people would like to try it on their setup if it works for them, too, and when we could better understand why this desyncing occurs and how to build workarounds into base-OBS.
dojima
commented
1 year ago I use the async audio filter as well, and while it's a wonderful plugin, its functionality is, I think, unrelated to this issue.
Is the Audio Output Mode OS specific? I know DirectSound is Windows only, but I would assume other OSs have their own APIs for audio output. I don't think anything I said should be specific to Windows. The last note I made was just an ancillary quibble about a potential nice feature addition.
PipeL1n3
commented
1 year ago Hmm, i don't even know where to find Audio Output Mode option? And what you mean by "output desktop audio". OBS works with devices via the systems foreign APIs, so "Desktop Audio" ist just an Alias to the Device you chosen in settings to be the Desktop Audio Device, it has not to be the default device anyway, but could be all sound device you have connected to your computer, even virtual device such as voicemeter inputs etc.
And yes it might be that the async-audio-filter won't fix the buffer buildup on Monitoring, but maybe it helps OBS to keep it in sync generally on my setup it is permanently adding some samples to my OBS-teleport-source (which works like NDI) and maybe it is part of the solution but not all of it. As mentioned toogling monitoring off and back on normally fixes the problem for some time, the python script i linked does a wonderful job on doing it automaticly and i do not even notice sound-crackling or something like that when its doing it. So maybe give it a try. I don't have tested these two fixes seperatly, so i do not really know which does the trick, but in combination its doing a wonderful job, at least for a couple of weeks now.
dojima
commented
1 year ago Audio Output Mode is a setting for video capture devices. Using this to output audio enables you to monitor audio without drift.
PipeL1n3
commented
1 year ago ok got, it its documented here: https://obsproject.com/wiki/Sources-Guide#video-capture-device
The Video Capture Device Source allows you to add a variety of video devices, including but not limited to webcams and capture cards. On Windows, for a device to work with OBS the drivers needs to support DirectShow output. Since DirectShow is the standard output format for Windows, there's a good chance that this is what your device outputs. All major webcams and capture cards support DirectShow and will work with OBS.
Which, indeed, means it actual is OS-related as directShow is windows-only. OBS is using video4linux (V4L2) on linux systems to capture devices like this. I don't remember seeing this option there, but anyways its not fixing problem. Some won't want to output sound of such device to desktop-audio as you are losing ability mixing it separately in OBS. And also its not even an option for people having issues with monitoring delay from other sources exp. NDI-Sources or OBS-Teleport Sources or any kind of browser-sources. If it does it for your usecase, its good for you then.
joelcarlton
commented
1 year ago This has been an issue to us as well; after using OBS for years we starting having audio drift. The only solution we have found was to use external plugins, but those plugins ended up introducing bugs that needed to get fixed. Those patches forced us to have to move to v28. So we moved from v26 to v28.
I honestly don't understand how OBS does not include audio out with the virtual camera. If there is a virtual camera that can be used with zoom, then OBS should also include a virtual audio out to match and stay in sync.
AaronD-GH
commented
1 year ago I honestly don't understand how OBS does not include audio out with the virtual camera. If there is a virtual camera that can be used with zoom, then OBS should also include a virtual audio out to match and stay in sync.
I posted this on OBS's "Ideas and Suggestions" forum, about a week ago: https://obsproject.com/forum/threads/add-a-second-audio-out-like-the-monitor-but-for-the-main-audio-instead.162376/ Would it solve your problem too?
conlanpatrek
commented
1 year ago Just had my ticket closed as a dup, makes sense. Adding in that this is still an issue on 29.1.3 and it affects Mac as well as Windows (this ticket is only labeled Windows). My offset increases over time and will be off by a matter of minutes near the end of my stream. The monitor is unusable by that time
conlanpatrek
commented
1 year ago @Fenrirthviti I'm seeing that this is a 2 year old ticket for 3 major versions back. Is it fair to assume this won't get priority even with the added OS and version context? If so I'll have to find another solution.
MarcusBuer
commented
1 year ago @conlanpatrek I don't think it will be fixed without some TLC on the monitoring. For now you can use this script to reset the monitoring every few minutes, so it doesn't desync over time.
conlanpatrek
commented
1 year ago @MarcusBuer Thanks for the tip! I've opted for exceldro's audio monitoring plugin for the time being, but if that doesn't end up working out I'll definitely read through your source and give it a try.
Fenrirthviti
commented
1 year ago The tl;dr at this point is that to fix this, we would need to rewrite large parts of the audio subsystem, which is a heck of a lot of work and something we haven't had the time for. We haven't forgotten about this, though.
conlanpatrek
commented
1 year ago @Fenrirthviti Thanks for the response. I'm not historically a c / c++ guy, but I've done a little. I don't suppose there's anything I can do to help? Or do you keep patches closer to the chest than that?
Fenrirthviti
commented
1 year ago We certainly welcome any contributions, but I'm not the best positioned to explain what all needs to be changed/updated from a deep technical standpoint. I can say that the audio subsystem is one of the most complex, and fiddly, parts of OBS, which is part of why this has been waiting for so long.
AaronD-GH
commented
1 year ago The tl;dr at this point is that to fix this, we would need to rewrite large parts of the audio subsystem, which is a heck of a lot of work and something we haven't had the time for. We haven't forgotten about this, though.
We certainly welcome any contributions, but I'm not the best positioned to explain what all needs to be changed/updated from a deep technical standpoint. I can say that the audio subsystem is one of the most complex, and fiddly, parts of OBS, which is part of why this has been waiting for so long.
At that point, maybe a complete overhaul to make it more like a professional workflow wouldn't be such a wild idea. Take cues from a bunch of different DAW's and physical consoles, but with less functionality of course. No sense in reinventing all of that when we can just feed OBS externally from one of those.
Or maybe do something like this?: https://ideas.obsproject.com/posts/2137/audio-overhaul
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
2021-04-15 11-03-34.txt
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
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.