Random short audio dropouts when recording or streaming

[floele]

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:

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

1. Launch OBS.
2. Start test tone (I use https://www.szynalski.com/tone-generator/).
3. Record desktop audio using OBS (all default settings) and wait.
4. 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.

[WizardCM]

To confirm, this issue is not new in 27, as you've verified it in OBS 26.1.1?

[floele]

Yep, I have been investigating this in 26 already and only confirmed that it's still there before reporting.

[DJ-3ncoder]

I found a simillar or maybe the same issue in my latest stream recordings.

My software and hardware:
OBS 27.0.1
Windows 10 64bit
Focusrite Clarett 4Pre USB

My signal chain: Pioneer DJ Mixer puts out 48kHz signal via S/PDIF into the Focusrite Clarett.
The soundcard gets the S/PDIF clock from the mixer and is locked to it.
Every soft- and hardware is set to 48kHz.

On the top there is the recording done with Audacity and on the bottom there is the audio-track from the recorded video.
Recording is set to "stream encoder" (nvenc), mkv and remux to mp4 afterwards.
The drop-out occurs in the mkv and mp4.
Both audio-tracks are recorded using the same interface on the same computer. Audacity looks fine but OBS is struggling.

After scrolling through the waveforms I found this:

To get the first picture I aligned the waveforms after the drop-out. The second picture is before the audio-drop out.
You can see that the waveforms are not aligned. The bottom waveform (=OBS) is earlier in time.
After seeing that I was thinking that the drop-out is more like a "break" in the signal because when you delete it and move the bottom waveform to the right, both are aligned all the time.

These drop-outs or "breaks" happen randomly. I do not click anything because in the video everyone can see that I am not in front of my PC.

Due to the fact that the Audacity recording is fine on the same PC I think this issue is caused by OBS.
I do not know if it occurs in the stream too, nobody is listening that carefully.

Log-file: https://cloud.3ncoder.com/s/nsS7n98QYED9Tnr

[konsolenritter]

Unfortunately i must confirm. Still using obs 26.1.1 under win10. All sound devices disabled but a steinberg ur-22. External playback of 1khz tone. i7 10th generation nearby idling.
With recording or streaming the same experience: By chance (random) happen such short dropouts. Sometimes once within in a couple of minutes, sometimes two dropouts within 20 seconds or even less. Randomly distributed.
The try/workaround as of user floele i find very interesting.

Due to the nature of live events in the case of streaming people tend to be forgiving alot, especially in the case of ultra-short outages (its almost anticipated these days). But even then a short cut on audio is more distracting then a few lost frames. So ever stable audio wins (and is more important) over stable video for normal broadcast.

Would be unbelievable happy if that nasty thing could be fixed.

[floele]

Unfortunately I did not have time too look into the issue futher, just wanted to share the last thing I found out.
It looks like (at least on my PC) I'm dealing with two different kind of dropouts. A frequent one (occurs roughly every 5 minutes) and an infrequent one (maybe each 30 min.).

I was able to fix the frequent one by changing the sleep method to a more precise alternative (example commit floele@a34fda1), but the issue I actually want to fix is the infrequent one because it reproduces on the machine I'm concerned about (and many other machines as far as I know). This one does not seem to trigger a “can't discard, data still pending” debug message so at this point I'm not sure when it is triggered or what is causing it.

[konsolenritter]

Is anybody else working on that issue here?
My C or C++ is fifteen years ago..., so there is a little rust around. ;)
I could imagine to invest a couple of hours into the obs-audio world over the next few weeks. My problem is, that i don't have a working environment to test and compile for windows here by myself. I'm totally fan of free software, but when it comes to ms studio or something alike... shiver

[DJ-3ncoder]

I found out that the problem that I am facing occurs at around 1h 7min of stream/recording time. It occurs only once but everytime at the same time!

Audacity recordings are fine. Changing the buffer size in the Focusrite panel makes no difference.

Maybe I can find out how to change log level to debug or so to find out what happens at 1h 7min.

[bnacar]

It's not just on Windows. This has been happening to me during livestreams and recordings on both MacOS and Linux, on average once every ten minutes. Just now I was able to replicate this after compiling from the latest source on Linux (Debian Stable). With OBS and Audacity recording simultaneously for fifteen minutes, I got two dropouts in the OBS recording and none from Audacity.

@floele were you ever able to pinpoint the cause of the less-frequent dropouts?

[floele]

Unfortunately I have not yet looked into it any further...it's still bothering me though.

[DJ-3ncoder]

Since the beginning of 2022 I tried the ASIO plugin for OBS.
I set my input accordingly and the drop outs are still there.

I also tried on a different computer (but the same soundcard). Same result, 1 drop out at timestamp 01:xx:xx of recording.

I am still shure that this bug is caused by OBS itself and not by my soundcard. It annoys me very much.
Is there a way to change log level in OBS? I want to find out what is happening at that time.
Normal loglevel does not log that drop out.

[floele]

If you combile OBS yourself you can enable the DEBUG_AUDIO flag for more logs.

After fixing one of the issues (the frequent dropouts) there weren't any relevant logs left corresponding to the occurrences of the issue on my PC though. So it's likely that these logs won't help you at all.

I also tried ASIO without success.

[konsolenritter]

Hi floele, what is the toolchain needed to compile obs myself for/under win10? How much effort? Is there a clear documentation for this? My IMHO feeling is that the problem is bound by the amount of samples obs reads each cycle in the audio thread from the samplequeue, and how this thread is triggered. Is it a fixed timing, a kernel timer based, or something else? Do you know something about? Greez, #timo Am 10.02.2022 um 23:07 schrieb floele:

…

If you combile OBS yourself you can enable the DEBUG_AUDIO flag for more logs. After fixing one of the issues (the frequent dropouts) there weren't any relevant logs left corresponding to the occurrences of the issue on my PC though. So it's likely that these logs won't help you at all. I also tried ASIO without success. — Reply to this email directly, view it on GitHub <#4600 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANLNV47JOTGCLW2Y2UFQXKTU2QZINANCNFSM43TMLWEQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[floele]

Yes, there are build instructions available. I would link to it, but apparently there is currently some reorganisation happening and the page asks not to link to it for the moment. So just look for it on Google ("Build Instructions (Windows) - OBS Studio").
You basically only need VS 2019 with C++ and install some additional tools (like QT). It's doable.

As for the issue, I've been focusing on https://github.com/obsproject/obs-studio/blob/master/libobs/media-io/audio-io.c and https://github.com/obsproject/obs-studio/blob/master/libobs/obs-audio.c but I'm starting to believe that maybe the issue might be at a later point in execution, maybe the muxing process.

The reading is basically sleep() controlled as far as I can see. As per my previous comment, this seems to be unreliable on my hardware so I replaced it with a different method, but that doesn't solve the problem everyone is having.

[Fenrirthviti]

apparently there is currently some reorganisation happening and the page asks not to link to it for the moment.

Where exactly are you seeing this comment? Our official build directions are on our Wiki pages here: https://github.com/obsproject/obs-studio/wiki/install-instructions

There is a pending cmake rewrite that will change how some things work at a high level, but the overall process should be largely unchanged.

[bnacar]

I tried adapting @floele's solution - of making the sleep time in the audio thread more precise - for Linux, and for whatever reason, it didn't affect the frequency of the dropouts (on my system anyway). I did several other experiments and this what I observed on my system:

The vast majority of audio dropouts that I've encountered are indeed correlated with the "data still pending" message, and these dropouts have a duration equivalent to whatever I set AUDIO_OUTPUT_FRAMES to. Using Audacity to visually inspect the recorded audio, the waveforms at the beginning and end of these dropouts line up, i.e. audio data is getting delayed, not deleted, and delayed by just about one sleep cycle.

In addition to making the sleep time in audio_thread more accurate, I tried setting AUDIO_OUTPUT_FRAMES to 768, which corresponds to a nice round number of 16 milliseconds when recording at 48kHz. Unfortunately this didn't make any difference either.

I'm not familiar with what sequence of events will deterministically result in a call to add_audio_buffering, but I tried modifying this function to add an absurd amount of buffering when it does get called:

- ticks = (int)((frames + AUDIO_OUTPUT_FRAMES - 1) / AUDIO_OUTPUT_FRAMES);
+ ticks = (int)((frames + 3 * AUDIO_OUTPUT_FRAMES - 1) / AUDIO_OUTPUT_FRAMES);

On the occasions that add_audio_buffering does get called, the additional extra buffer results in an initial long stretch of recording (on the order of 20 to 30 minutes) completely free of dropouts, but over that time the buffer gradually shrinks until there isn't enough data available, and then the dropouts resume.

In short, audio data is being output slightly faster than it gets added to the buffer. If this discrepancy is unavoidable, the permanent solution might be closer to the original proposed fix of adjusting the sleep time on the fly with extra wait cycles (I haven't tried this myself yet).