New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pulse: fill audio monitor buffer more aggressively #4908
Conversation
Right now this logs whenever the pulse monitor underflows. This occurs probably more often then people think but generally isnt an issue (when audio sources are muted/end, similar underruns are reported in things like firefox and mpv for me) but I left the logging in. It may be better to turn it off unless we reach the 1s latency threshold. |
After testing this, I found that the latency doesn't increase over time, but there is a noticeable initial latency when first enabling monitoring. After a restart of OBS, there is no noticeable latency. However, changing from "monitoring disabled" to "monitoring and output" sometimes crashes OBS with this Side note, it doesn't fix #4759. |
Log. Nothing suspicious, and Pipewire doesn't report anything either where it used to report underruns. The issue might be in Pipewire, I haven't tried this PR with PulseAudio yet.
It happens with either a PulseAudio input source, a media source or a Jack input source. When OBS crashes, this appears in Pipewire logs:
|
Yes i can replicate the crash, but i was more concerned with the crackling. You should be observing the pipewire-pulse logs not the pipewire logs for events related to over and underrun that might be causing cracking. In this case it seems that pulseaudio is not reporting under runs to OBS so something else is causing your crackling. Please provide an example audio file that you are using in media source if you can. |
I am observing the
Here you go: valse-gymnopedie-by-kevin-macleod-from-filmmusic-io.zip |
So you see no under/over runs in any logs but still hear crackling? I have tried with your example file and dont hear any cracking or when adding other media sources and jack sources and monitoring them (4 monitors running). |
No, nothing in the logs. The crackling happens when you lower the output volume and gets worse as you go down. Here's a capture (beware, loud audio): capture.mp4 |
Right that doesnt occur for me on the old or the new code, Im not sure what the source of that particular issue is for you but since you dont see underruns or overruns its unrelated to this code I suppose. I'd ask you replicate that effect on pulse audio and if it replicates we can reopen your bug otherwise file a bug against pipewire for that one. |
It works as expected with PulseAudio. I had already opened an issue against Pipewire: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1238 |
Updated the write checks and it no longer crashes on my machine, thanks for finding that! |
Previously we would wait for pulse to attempt to read from the monitor source and obs buffered at least 5ms of audio data before we tried to fill the buffer. In some cases this resulted in consistently triggering underruns in pulse. Instead we try to fill the buffer immediately as obs outputs audio data and while the pa buffer is not full. We also stop trying to grow the buffer to prevent underruns after we reach 1s of latency.
I can confirm that it doesn't crash anymore on my side either, and the initial latency when first enabling monitoring disappeared. |
The patch #4908 is good for me, no lag for hours on Debian 10 but only for input device, no change for medias. |
I tried out this branch. It did improve the increasing lag over time but did not remove it. The stock version 27 of obs, the audio would fall behind 2-3 seconds every 30 min. This PR improved those times to 2-3 seconds over 4 hours. So much better. No other issues so far (only been using for a day). How I measured : kinda janky. If anyone has a better measurement methodology I'd be happy to try it. |
Prior to applying this PR, I experienced stuttering when attempting to play a FLAC file either with the media source, or a VLC source, Fedora 34, Pipewire 0.3.36, OBS master branch. I also experienced stuttering on OBS studio 27.0.1 from RPM fusion. This PR completely clears up stuttering output for me. I have not tested any capture scenarios. |
I tried the drop-in replacement of Pulseaudio with Pipewire (version: 0.3.38) on Arch Linux and it resulted in monitored audio being broken completely (crackling audio, cutting out audio and so on). Applying this PR fixed the issues when the audio source volume was at 0,0db, but introduced the same issue that rmnvgr had: #4908 (comment) |
After going back to PulseAudio with PR applied (in a local portable build) and without the PR applied (a package from AUR), I can reproduce #4908 (comment) with PulseAudio as well. |
Audio at lower volumes being wrong appears to be fixed by #5400 , if you could try that and this commit. |
According to Zulleyy3 at a discussion on discord, the audio volume bug is fixed on their host. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took some time to properly understand the PA API, and the differences between this branch and main, and AFAIU this is correct. Bonus points for getting rid of a lock + unlock 🙂
Tested on PulseAudio and PipeWire, both are working as expected. So 👍 from my side. Thanks!
Does this fix the issue across all platforms, or just Linux? Sorry for the stupid question but I'm not familiar with this codebase. |
Hi @teaStudios, |
Hi @norihiro I've seen posts about this exact bug on windows as far back as 2016 which is unfortunate. |
Description
Previously we would wait for pulse to attempt to read from the monitor
source and obs buffered at least 5ms of audio data before we tried to
fill the buffer. In some cases this resulted in consistently triggering
underruns in pulse.
Instead we try to fill the buffer immediately as obs outputs audio data
and while the pa buffer is not full. We also stop trying to grow the
buffer to prevent underruns after we reach 1s of latency.
Motivation and Context
Attempting to fix #3525
How Has This Been Tested?
Adding a media source with an mp3 gave consistent underrun's with the old code. After these changes there are no more under runs reported from the pulse log or obs.
Types of changes
Checklist: