Random short audio dropouts when recording or streaming

floele commented 3 years ago

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

27.0.0-rc2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://pastebin.com/WfdNU2QN

OBS Studio Crash Log URL

No response

Expected Behavior

Audio recording without dropouts.

Current Behavior

When recording or streaming, audio data contains multiple random short audio dropouts.

Looks like this: grafik

Distribution of the dropouts seems to be random but happen at a certain rate depending on which computer it is being run on. On my computer it’s approx. every 5 minutes, I have seen it on another computer where it happens roughly twice per hour. For a 40 min. test recording on my computer, dropouts have occurred at these time stamps: 00:03:19 00:09:40 00:15:38 00:19:51 00:23:41 00:29:55 00:36:07 The length of the dropouts are not necessarily all the same length.

Steps to Reproduce

Launch OBS.
Start test tone (I use https://www.szynalski.com/tone-generator/).
Record desktop audio using OBS (all default settings) and wait.
After stopping the recording, audio dropouts can be found in the resulting file.

As indicated above, the frequency of this issue seems to depend on hardware and may either not occur at all or very rarely on some systems, I'm not sure what it depends on.

The issue can also be reproduced without using a test tone of course, but a continuous tone makes it easier to check the resulting file for dropouts.

Anything else we should know?

Conditions

I have been testing on Windows 10 20H2 with OBS 26.1.2-276 and 27.0.rc2, 64 bit, without any video source configured (issue also happens with video configured though).

The issue seems to be independent of OBS settings (like audio sample rate or output format). I have not yet found any setting in the OS (like energy settings) that fix or reduce the issue.

The frequency of the issue seems to depend on the hardware. There are systems where I was not able to reproduce the issue, though I did not make excessively long recordings (> 4 h) to eliminate the possibility of the issue occurring on these systems.

The issue is not limited to recording from desktop audio but also applies when recording from external USB audio interfaces.
The issue is not limited to recording but also applies to streaming.

When an audio dropout occurs, the message “can't discard, data still pending” is seen in the debug output (if compiled with DEBUG_AUDIO).

The attached log file includes a debug message (Capture size: 480) I added, it outputs the captureSize variable in ProcessCaptureData() to check for any changes in amount of data being returned there.

Debug attempt

I’m not familiar with the OBS code base and the audio processing happening, but to me it seems like the problem is the fact that in audio_callback(), it always takes a fixed amount of data from the audio buffer (audio_size = AUDIO_OUTPUT_FRAMES * sizeof(float)) even if the buffer is not sufficiently filled due to potential delays in the capture thread.

What I have tried to solve this issue is basically waiting for the buffer to be filled, like this in audio_callback.

        if (!source->audio_pending && source->audio_ts > 0) {
            int iterations = 0;
            while (source->audio_input_buf[0].size < 4096) {
                blog(LOG_DEBUG,
                     "waiting 2 ms for audio buffer to fill (%s)",
                     obs_source_get_name(source));
                os_sleep_ms(2);
                iterations++;
            }

            if (iterations > 0) {
                blog(LOG_DEBUG,
                     "waited %i iterations for the audio buffer to fill",
                     iterations);
            }
        }

This significantly reduces the number of dropouts (on my system to like 1 in half an hour), but it’s not a good solution because additional to not entirely fixing the issue it doesn’t recover from the situation and adds continuous wait cycles after the first dropout that far exceed the number of dropouts that would have actually occurred. Also it seems kind of wrong to me doing that in the first place.

I would appreciate some guidance or a fix for this issue.

floele commented 2 years ago

@bnacar I pushed a new version with a modification to the “can't discard, data still pending” fix. Video should be in sync now. But as I mentioned before, I couldn't see any problem with my other fix. I recorded this video for testing and compared the sound to the visuals in the resulting OBS output video: https://www.youtube.com/watch?v=Wtt9aK27mes

Previously, there was a very noticable video lag, which is now gone. Maybe you can test using this method as well? Not sure if I trust clapping enough to reliably spot subtle differences. Though maybe you get different results when using different input devices. I'm only testing with desktop audio and desktop video so far.

bnacar commented 2 years ago

@floele Using your last update, I confirmed that if I just use desktop audio and video, that stays in sync. I also did several hour-long tests with multiple combinations of input devices and found that some stay in sync and some don't. (The accumulated lag over 1 hour is less now than before your last update, 4-5 video frames instead of 10 or more.) Then I repeated my tests with an unaltered compile of OBS and found that while most of them stayed in sync, there were certain combinations that didn't, although in those cases the drift was less than happened with the fixes.

So I'm starting to think this is a separate issue... anyone else in this thread have any recent test data to share?

floele commented 2 years ago

Hi @bnacar , thanks for your feedback. I checked for one last potential issue today but didn't find any more issues with my changes so I'd like to proceed with getting them reviewed.

What you describe so far doesn't seem like the original issue that DJ-3ncoder confirmed and I was able to reproduce and fix, the delay was quite noticable previously (no "frame by frame" analysis was needed to notice) and it also accumulated pretty quickly.

If you you have any evidence that suggests my changes might make things worse, please let me know though.

@jp9000 I'll update my PR to "ready for review" now, please let me know what you think about the changes :)

bnacar commented 2 years ago

@floele I agree. Thanks for all your work on this!!

norihiro commented 2 years ago

Hi, I've created an audio source plugin to reproduce the bug easily. I assume the root cause of the issue is a skew of the clock source between the audio source and OBS. The plugin simulate a slower or faster clock in the audio source and generate a sine wave. https://github.com/norihiro/obs-asynchronous-audio-source I hope this is useful to debug and find the way to fix the issue.

cattywampus04 commented 2 years ago

Hi there, I have just done a recording using build 27.2.0-36-gfb1b8efe1 using my GOXLR, which had the stutters/drop outs...and there are no stutters/drops on the recording! Considering 100% of my previous recordings with the GOXLR had stutters/drop outs, I think this is a great sign.

I made a mistake by not plugging my camera in while recording to check for any sync issues, so I will do another recording over the next couple of days with the camera to check for sync issues.

The "use device timestamps" option for the audio devices, what should that be set to? The recording tonight I had it unchecked...but in the past i've always had them checkboxes ticked if they were available.

Thanks for everything you guys have done ♥

norihiro commented 2 years ago

Just FYI, 27.2.0-36-gfb1b8efe1 is the PR build for 9875b64. (You can see the green check to see the commit hash for PR build) https://github.com/obsproject/obs-studio/compare/9875b64

floele commented 2 years ago

@Stuwot I don't think the "use device timestamps" option matters. You can experience the issue both with this option enabled and disabled. However, for a proper test, you should use the same state for both recordings.

norihiro commented 2 years ago

The "use device timestamps" option for the audio devices, what should that be set to?

The default is as below. I don't know the reason but it would be better to set the default if you don't have paticular reason to change.

Source	Use Device Timestamps
Audio Input Capture (Mic/Aux)	unchecked
Audio Output Capture (Desktop Audio)	checked

cattywampus04 commented 2 years ago

Hi guys,

I am really sorry but I am getting super confused as to what I should be downloading to test?

Just FYI, 27.2.0-36-gfb1b8efe1 is the PR build for 9875b64. (You can see the green check to see the commit hash for PR build) https://github.com/obsproject/obs-studio/compare/9875b64

I used 27.2.0-36-gfb1b8efe1 to test yesterday and the recording was fine. I tried the same build on my main streaming PC that has my camera attached to it, and that has some crazy glitches in the recording. I'm still listening back to it, only 40 minutes into a 90 minute mix, but there have already been 2 of these glitches.

I want to be able to help and test, but I am really confused. Is there more than 1 audio problem you're trying to fix? Is there more than 1 build you're working on to try and fix these problems? I don't understand GitHub like you guys do, so I'm just generally confused where I am supposed to be looking for what to grab to test.

If you feel its not something you can explain to me in a short post and would prefer me to just sit this out, then I understand.

Sorry for being a pain.

EDIT: Just to say what I did to run the build with the fix:

I went here https://github.com/obsproject/obs-studio/actions/runs/1888691307, downloaded the Win 64 zip, extracted it and then copy and pasted the 3 folders into my obs-studio folder in Program Files and overwrote all files. Was that right? I've since seen that the fix is actually contained with in 1 file only?

One last edit: The recording I made tonight, the one with the glitches, the audio and video drift out of sync. Device timestamps are set to defaults.

floele commented 2 years ago

@Stuwot There are in fact two separate issues. Both of them are included in the same PR though. And yes, there are multiple builds, since a new one is generated each time a change is made. So if you want the latest one, go to https://github.com/obsproject/obs-studio/pull/5993/commits, click the green checkmark and then go to the multiplatform build, you'll find the artifacts on the summary page.

The one from 12 days ago is fine for testing though because there have only been cosmetic changes after that.

downloaded the Win 64 zip, extracted it and then copy and pasted the 3 folders into my obs-studio folder in Program Files and overwrote all files. Was that right?

That should work though I think you can just run OBS from the extracted folder as well? Might be a safer option for testing.

cattywampus04 commented 2 years ago

Hi @floele thank you for explaining that. I'm really just not used to using GitHub beyond downloading releases - so all the "PR" and "commits" and what not were just going over my head slightly - I did some basic reading and I think i understand the process a little better now. Thank you though.

Yes you are right about just running OBS from that extracted folder. I never thought of doing that. I've done that now. I've just recorded a mix and am listening back to it now. Will report back with the results.

Do you happen to know whether these issues that you have hopefully fixed will cover things like the OBS ASIO plugin audio too? I've been using that plugin to capture the Line-in port on the GOXLR as it's the only way to capture it in OBS. I was having the stutters/drops whether I was capturing audio using the "audio output/input capture" sources and with the ASIO capture source plugin - exactly the same issue. I would record to multiple tracks - so I would send one mix to track 1 and then capture the audio through ASIO too to another track, and there would be stutters/drop outs but they would be in different spots for each track. Hope that makes sense. Edit: I did the recording I am listening to now without ASIO installed, just to rule it out of being an issue.

Thank you for what you guys have done.

Oh, and how long does it take for your fixes to be rolled into the main release of OBS? No rush, just interested in the process out of morbid curiosity :)

floele commented 2 years ago

@Stuwot Thanks for testing! The issues are independent of the used plugin so that should work fine too.

As for release schedules, I'm not the right person to ask, but so far we still have not confirmed if the changes are correct and free of regressions so it might be a little too early to talk about that.

cattywampus04 commented 2 years ago

Thanks @floele

I was just typing a message to say that I was still getting the stutters on my streaming PC...but as I am typing to report, I looked to my stream PC where I have yet to have a stutter-free recording to tell you that I was using the most current PR build...and I realise that the entire 90 minute test mix I recorded in OBS-proper 27.2.3 😂😂 I was having problems with adding my camera, so I was back and forth loading OBS-proper and the PR build and I have forgotten to load back up the PR build before recording 🤦‍♂️🤦‍♂️🤦‍♂️😂

Smart, I am not.

I also have just sat and listened to the playback of the mix, so that's 3 hours wasted 😂😂

Still, at least the hope is still alive that the PR build will result in a flawless recording. I'll do another test tomorrow - in the correct version of OBS though 😂😂😂

bnacar commented 2 years ago

In case it helps to try and replicate the tests I'd been doing:

To test for dropouts: record an hour or more of desktop audio, using the tone generator linked in the original problem description. Then instead of listening to the whole thing, you can open the recording in Audacity and scroll through an hour's worth in a few minutes and visually check for anomalies.
To test for sync of video and audio: clap your hands in front of the camera a few times at the beginning of the recording, walk away for an hour or more, clap your hands in front of the camera again. Then you only need to watch the very beginning and very end.
To test for both dropouts and sync, without getting bored on playback: record yourself playing an instrument for an hour or more (less foolproof if there are moments of silence in the music).

cattywampus04 commented 2 years ago

Hello!

So I have now done 2 recordings, both 90 minutes long using the March 2nd (I think that's the date) PR build. No plugins. 1 scene with just my camera source and the audio device source...and I think we're good. The first recording had a tiny blip, but it didn't sound the same as the dropouts/stutters. I recorded on 2 computers using the same build and scene/source layout - and the blip wasn't on the other computer's recording. But there were no stutters or dropouts like happens with OBS-proper.

I am going to do some more tests though to be sure. I am going to add my other audio devices and record multi-track like I would be doing if I was streaming, and then I will test with all my normal scenes, sources and plugins installed and set up.

It's looking promising though.

cattywampus04 commented 2 years ago

Another test done tonight. I just went straight to testing with all my normal scenes and plugins (excluding the ASIO plugin) set up...no stutters or drop outs! An awesome sign. Am going to keep testing - though for me there is really only one more thing I need to add back in to my setup....the ASIO plugin.

To save me keep adding on to this, should I only add more on to this thread now if I encounter any dropouts/stutters and we just consider the problem solved with your fix?

floele commented 2 years ago

Please do post positive test results. However, I'd be more interested in whether or not you see any negative side effects of the fixes (like audio/video out of sync) rather than the absence of dropouts. At this point I am reasonably confident that the changes actually fix the issues I wanted to fix, now we primarily need to confirm that everything else if unaffected.

cattywampus04 commented 2 years ago

Hello.

So I have been doing more testing and unfortunately, as others have discovered, the audio drifts out of sync over time. I tried with and without device timestamps checked. Both the same. I am doing a test in the main release build just to double check its not drifting on that too, and I will do another test using the motherboards internal audio.

Is this likely to be a hurdle that cannot be gotten over, being able to sync audio and video proper?

Thanks.

norihiro commented 2 years ago

Hi @Stuwot, If you are interested, could you try another possible-solution that I made? It's implemented as a plugin instead of implemented into OBS Studio itself.

You can download from this page. https://github.com/norihiro/obs-async-audio-filter/releases It should work with released version of OBS Studio but need to apply a filter Asynchronous Audio Filter to your audio source. You might experience small distortion especially on high frequency.

It's behavior is that it will detect the drift of the coming audio, then it will gradually remove or add samples to compensate the drift. The idea is similar to this article but my implementation is much more simplified than the article.

cattywampus04 commented 2 years ago

Hey @norihiro

Damn that sounds awesome! I am just testing the most recently PR build that @floele has put out. I'm streaming to a burner Twitch account while recording so I can watch/listen to the stream and do some sync tests live while also recording to check later...and at the moment everything seems in sync. @floele suggested this sync issue could happen sometimes and not others though, and he also mentioned about there being 2 PR builds and one of them might not cause the audio drift. I wasn't sure whether he meant his latest build was one of the 2 and that's why the drift might not be happening this recording.

Anyway...that's a long way of me saying I most certainly will test your plugin if the drifting keeps being an issue. I've done a lot of tests lately and not done much proper production so will need to break away from testing at some point but will surely check it out soon!

floele commented 2 years ago

Hi @Stuwot , I updated the PR #5993 today with some modifications that address the concerns norihiro raised. Since I am still unable to reproduce the out of sync issue, it would be great if you could test the changes. This PR is still based on an older version of OBS and should work fine for testing.

@norihiro Can you explain how you see the issue we're trying to address? You mention a "difference of clocks" as source for the problems in your filter plugin description, however, I don't see any such issues for the cases I am looking into. Especially since the problem also occurs when you don't use any external audio devices. Are you looking into a different kind of problem?

Also, if some kind of "catching up" is implemented by adding for removing frames, shouldn't this be done in the video stream since adding or removing frames there would basically not be noticable?

norihiro commented 2 years ago

Looking at the log on this issue and Stuwot's log, I saw a kind of USB audio interface is connected. I assume they have separated audio input and video input.

My setup is (a) M-200i, which output AES/EBU digital audio, (b) PCM2906B Audio CODEC, a hand-made USB-connected AES/EBU receiver, and a PC running OBS Studio on CentOS 8. I'm seeing ~20ppm difference in between (a) and (c). I'm checking this article describing 'Asynchronous Mode', which I assume the root cause of the issue. Another journal on IEEE and ADI's Ee note describe the solution used in commercial products.

Also, if some kind of "catching up" is implemented by adding for removing frames, shouldn't this be done in the video stream since adding or removing frames there would basically not be noticable?

I agree that. Currently video capture sources provide an option Use Buffering. By disabling the buffering, the drift on the video should not happen as well. (This might degrade frames if frames does not arrive smoothly but working fine on my environment.)

cattywampus04 commented 2 years ago

Hi @Stuwot , I updated the PR #5993 today with some modifications that address the concerns norihiro raised. Since I am still unable to reproduce the out of sync issue, it would be great if you could test the changes. This PR is still based on an older version of OBS and should work fine for testing.

@norihiro Can you explain how you see the issue we're trying to address? You mention a "difference of clocks" as source for the problems in your filter plugin description, however, I don't see any such issues for the cases I am looking into. Especially since the problem also occurs when you don't use any external audio devices. Are you looking into a different kind of problem?

Also, if some kind of "catching up" is implemented by adding for removing frames, shouldn't this be done in the video stream since adding or removing frames there would basically not be noticeable?

Testing right now. I have been recording and streaming to a burner Twitch account so I can check the sync live as it's happening, but with this build, it would stream for ~60 seconds and then die. Is there something that is making Twitch consider the build not suitable? I tried streaming with the proper OBS build and it worked fine? Not a massive problem. Just thought I'd ask.

Would it be possible for you to briefly explain the 2 different issues that you are trying to fix? I have read through the threads but I'm not fully understanding what 2 issues are and which build fixes what? I don't need paragraphs and paragraphs. I would be helpful for me though to know and understand which issue is being fixed by which builds?

cattywampus04 commented 2 years ago

Looking at the log on this issue and Stuwot's log, I saw a kind of USB audio interface is connected. I assume they have separated audio input and video input.

My setup is (a) M-200i, which output AES/EBU digital audio, (b) PCM2906B Audio CODEC, a hand-made USB-connected AES/EBU receiver, and a PC running OBS Studio on CentOS 8. I'm seeing ~20ppm difference in between (a) and (c). I'm checking this article describing 'Asynchronous Mode', which I assume the root cause of the issue. Another journal on IEEE and ADI's Ee note describe the solution used in commercial products.

Also, if some kind of "catching up" is implemented by adding for removing frames, shouldn't this be done in the video stream since adding or removing frames there would basically not be noticable?

I agree that. Currently video capture sources provide an option Use Buffering. By disabling the buffering, the drift on the video should not happen as well. (This might degrade frames if frames does not arrive smoothly but working fine on my environment.)

Yes I am using a GOXLR Mini. When I use the Realtek audio line-in on the motherboard, there are no stutters. This is true on both of my computers. I get no syncing issues on the proper release of OBS either, just FYI 🙂

Thanks!

cattywampus04 commented 2 years ago

Hi @Stuwot , I updated the PR #5993 today with some modifications that address the concerns norihiro raised. Since I am still unable to reproduce the out of sync issue, it would be great if you could test the changes. This PR is still based on an older version of OBS and should work fine for testing.

@norihiro Can you explain how you see the issue we're trying to address? You mention a "difference of clocks" as source for the problems in your filter plugin description, however, I don't see any such issues for the cases I am looking into. Especially since the problem also occurs when you don't use any external audio devices. Are you looking into a different kind of problem?

Also, if some kind of "catching up" is implemented by adding for removing frames, shouldn't this be done in the video stream since adding or removing frames there would basically not be noticable?

Hi, this build is not working for me. I thought it was just streaming that wouldn't work and recording would be fine, but I just did a 90minute recording, only to find that once I pressed the stop recording button, the file size is tiny. It basically records 60-120 seconds of video, then just records audio, but really sped up. A 90 minute recording is only ~2 minutes long.

Tried multiple times and same result.

floele commented 2 years ago

@Stuwot Which build did you use? I tried OBS-Studio-27.2.0-f3b94c752-Win64 today and it works fine for me. There shouldn't be any major difference to the previous build.

Would it be possible for you to briefly explain the 2 different issues that you are trying to fix?

OK let's make it TLDR: 1) Audio dropout or distortion, occurs roughly every 40 min. or so. Fixed in #6133 or #5993 and the corresponding builds. 2) Audio dropout, may occur every couple of minutes. Fixed only in #5993 and the corresponding builds.

I'm not sure if either of these issues is reliably preventable by using audio interfaces that behave in a certain way. So for now I assume that both issues occur in a wide variety of configurations.

cattywampus04 commented 2 years ago

Thank you so much for that TLDR. I cannot stress how much that helps (and thank you for bearing with me on being slow on the uptake on things lol).

I have just had another bash with build 27.2.0-f3b94c752. I was running it with no plugins except the ASIO plugin so I could grab the line-in audio from my GOXLR. I've removed that plugin and am grabbing the audio a different way and it seems to be working ok now. I'm streaming and recording at the same time so am able to watch live and check the syncing. Does that having the ASIO plugin installed (which has worked fine on all other builds so far) sound like a plausible explanation for the problems I was reporting?

Any-who. I am doing a recording right now. Will report back.

Thanks again!

cattywampus04 commented 2 years ago

Hi, again!

So there is definitely something wrong with this build (27.2.0-f3b94c752). I'm running it with no plugins and I got 1hr 7m into a stream/recording and then it just gives up.

The first sign of trouble is the bitrate marker in the bottom right of the screen goes to 0kb/s...then after a minute or so I get a notif that the stream could not connect. If i then try and start the stream again, with the recording still supposedly going, it sits and thinks for a bit before failing to start again. Then, when I press the stop streaming button, that too sits there saying "stopping recording" - it sits like that indefinitely and I have to force close OBS if I want to be able to record and/or stream again using that build.

THEN...when I go and check the recording...even though OBS said it was still recording after it threw the error, the recording stops at that point. So OBS tells me the recording is 1hr 20mins at the point where I stop, but the file is 1hr 6m and it takes ages to seek around the file itself - as if something is corrupt in the file.

I've attached the log for the session. I got the stream error (where it drops to 0kb/s bitrate before throwing an error) at 01:57am. OBS then continued supposedly recording for another 20ish minutes...which it didn't actually record anything.

Thanks

2022-03-23 00-50-40.txt

noodohs commented 2 years ago

I am just chiming in to say that I am having the same issue as originally described, short stutters that occur seemingly randomly throughout streams/recordings. The only thing I have to add that might be of some value is that I seem to only get them with devices that have ASIO drivers available. So, for example, I get them when I use my Audient EVO 8 or when I previously used the PreSonus Revelator io44, but I don't seem to get them when using something like my THX Onyx or Shure MV7 which only have "standard" Windows drivers. I have only tested this for half an hour at a time, so I can't be 100% certain of that, but that seems to be consistent. The only common factor I can think of is that these sorts of ASIO audio interfaces generally have internal clocks. Not sure if any of that is helpful, but just wanted to chime in to try and help get this resolved.

DonKatsu commented 1 year ago

I'm not sure if what I'm experiencing is this issue or something similar. CPU is 5900X, audio device is ALC1220, using pipewire.

What I'm experiencing extends to output as well. While recording with OBS, I will occasionally hear a skip that ends up in the recording. These skips coincide with an increase in ERR counts for all processes listed in pw-top, including the output and input themselves. OBS gets more counts than the other process, and the output/input get the least. It seems to happen more frequently the more output audio sources I have set and mixed in OBS. Multiple obs-pipewire-audio-capture sources especially. However, pipewire services aren't reporting xruns in any case.

Verbose log of a 21 minute recording. The only audio sources were my output and USB mic selected in Settings>Audio>Global Audio Devices. Desktop Audio on track 1 and 6, mic on track 2 and 6. At some point in this recording, I got Audio timestamp for 'Mic/Aux' exceeded TS_SMOOTHING_THRESHOLD, diff=70042268 ns, expected 69524630824508, input 69524560782240. That should be around 16:13 but the closest dropout I can see at a glance is at 17:54. Screenshot. Track 1>Track 2>Track 6. You can also see track 1 lagging behind track 6. It does this from the very start of the recording. Any track with more than one source mixed seem to start faster than tracks with a single source?

Audacity unsurprisingly picks up these drops if ran alongside OBS. Audacity recording on its own doesn't see any drops, and pw-top doesn't gain any ERR counts. Game used for everything is Deep Rock Galactic, which is fairly CPU intensive.

EDIT: Tried changing some pipewire/wireplumber settings. Increasing clock.min-quantum stops the errors entirely, but needs to be set to 1024. Errors still happen at 512. But from what I can tell, changing this value isn't recommended. Increasing api.alsa.headroom seems to only help prevent the output from gaining errors. The OBS process still generates them, with the other processes in the output gaining a lower amount. Tried up to a value of 4096.

Still not sure what to make of this. Pipewire issue? Seems like OBS doesn't have enough quantum since the output gets set to 256 with Proton.

moonlightes commented 1 year ago

Hello. I'm using the motu m2 audio interface and I have a similar problem. I understand that no solution was found?

dojima commented 1 year ago

The solution I found was to use norihiro's asynchronous audio filter plugin. Works perfectly in my testing.

moonlightes commented 1 year ago

I have tried using this. But with the plugin, the sound stutters.

dojima commented 1 year ago

What is your use case exactly? Which sound stutters; what you hear or what is recorded or both? Did you make sure to use the plugin on all audio sources in your scene?

norihiro commented 1 year ago

I have tried using this. But with the plugin, the sound stutters.

I'd like to suggest creating an issue on https://github.com/norihiro/obs-async-audio-filter/issues so that the topic on this thread is focused on obs-studio itself.

moonlightes commented 1 year ago

What is your use case exactly? Which sound stutters; what you hear or what is recorded or both? Did you make sure to use the plugin on all audio sources in your scene?

Quite possibly I did not understand how to use the plugin. I installed it and added a filter for the microphone and windows sound, then I launched the tone generator. Clicks are heard on the recording, and the more samples the plugin adds, the more often they.

AlexGxtr commented 1 year ago

The logs for this run have expired and are no longer available. Trying to dl this for windows

AlexGxtr commented 1 year ago

Could you pls upload again the updated files for obs. I'm having the same issue.

moonlightes commented 9 months ago

Obs v30 in release and the problem is still present. Hardware: motu m2. --verbose when stuttering shows: "Audio timestamp for 'Playback Device' exceeded TS_SMOOTHING_THRESHOLD" and the same for the microphone obs-async-audio-filter helps in my case. Is it such a rare problem that it remains unresolved after all this time?

0x01011970 commented 8 months ago

I can confirm the problem is still present on windows.

I could confirm the issue is happening in OBS by recording audio at the same time in OBS and in Bitwig (for ASIO) and Audacity (for WASAPI).

Both on a Focusrite USB audio card (both ASIO & WASAPI) and on an onboard realtek audio card (WASAPI).

I tried both "Use Device Timestamps" enabled and disabled.

In every single tests, no sample drops can be seen in the raw PCM audio file produced by Audacity or Bitwig.

In every single tests, several sample drops can be seen in the recorded file by OBS (.mkv, .mp4, AAC or PCM 24 sle or 32 float).

I make sure all software and windows settings use same sampling frequency and depth.

CPU and GPU both bellow 50% usage, plenty of RAM & VRAM

There is also a secondary issue. By aligning the start of both sound waves, you can see the OBS soundwave is stretched over time. The OBS audio ends at a later timestamp than the one in Audacity or Bitwig. Logic would dictate since samples are missing in the OBS audio file that it would be shorter, but it’s the reverse.

I did not try https://github.com/norihiro/obs-async-audio-filter/, it is not a viable workaround.

AlexGxtr commented 8 months ago

I can confirm the problem is still present on windows.

I could confirm the issue is happening in OBS by recording audio at the same time in OBS and in Bitwig (for ASIO) and Audacity (for WASAPI).

Both on a Focusrite USB audio card (both ASIO & WASAPI) and on an onboard realtek audio card (WASAPI).

I tried both "Use Device Timestamps" enabled and disabled.

In every single tests, no sample drops can be seen in the raw PCM audio file produced by Audacity or Bitwig.

In every single tests, several sample drops can be seen in the recorded file by OBS (.mkv, .mp4, AAC or PCM 24 sle or 32 float).

I make sure all software and windows settings use same sampling frequency and depth.

CPU and GPU both bellow 50% usage, plenty of RAM & VRAM

There is also a secondary issue. By aligning the start of both sound waves, you can see the OBS soundwave is stretched over time. The OBS audio ends at a later timestamp than the one in Audacity or Bitwig. Logic would dictate since samples are missing in the OBS audio file that it would be shorter, but it’s the reverse.

I did not try https://github.com/norihiro/obs-async-audio-filter/, it is not a viable workaround.

Lower your master by 10-20-30db!!! Your signal is way too powerful so the audio is causing such issues.

obsproject / obs-studio