wwmm
Out-of-sync audio, and video playback stutter.
EasyEffects Version
8.0+
What package are you using?
Arch (easyeffects)
Distribution
Arch Linux
Describe the bug
With easyeffects 8.0+ any video played on YouTube of Twitch stutters a lot on playback for a few seconds when first played, and lose sync with audio in process. I have to hit play/pause, few times and it goes back to beign in sync, but everytime i skip few seconds i have to redo the play/pause thing. Any buffering that occures while playing futher desyncs audio and video. With versions below 8.0 i don't have any of those, video and audio always stay in sync.
Expected Behavior
Audio and video stay in sync.
Debug Log
Debug Log
Paste your log here
Additional Information
No response
With easyeffects 8.0+ any video played on YouTube of Twitch stutters a lot on playback for a few seconds when first played, and lose sync with audio in process.
Hum... I use these two sites regularly but so far I did not see this happening. What is the output of pw-top when this happens?
i am also getting stuttering, but i also get what sounds like 2 audio streams out of which at least 1 is crackling A LOT since the qt update. it made the app unusable, i am using the flatpak on nobara 42
i am also getting stuttering, but i also get what sounds like 2 audio streams out of which at least 1 is crackling A LOT since the qt update. it made the app unusable, i am using the flatpak on nobara 42
@Aragxmi what is the output of pw-top when these "2 audio streams" are present? I may also help to see easyeffects logs flatpak run com.github.wwmm.easyeffects --debug while they or the stuttering are there.
flatpak run pastebin
I hope this can be useful in some way. I am on pipewire 1.4.9 as per pipewire --version
2025-11-16T21:35:38.785Z | WARN | deep_filter_ladspa | DF 123f98c0e9f6 | Underrun detected (RTF: 1.13). Processing too slow!
@Aragxmi So far this is the only thing unusual I have seen in your logs. That together with a QUANTUM of 256 could be cause of the stuttering. It may be necessary to increase the latency a little. OR using the other noise remover that is a little nicer on CPU.
disabling it seems to have fixed my issues, but this wasn't happening prior to update and i am not quite sure what you mean by increase latency? thanks a bunch regardless!
disabling it seems to have fixed my issues, but this wasn't happening prior to update and i am not quite sure what you mean by increase latency? thanks a bunch regardless!
The quantum column in pw-top output is related to the latency pipewire is trying to use. Some systems do not handle well a quantum of 128 or 256. Maybe pipewire has always used this quantum on your computer. Maybe not.
A good test to make is closing the window. If the stuttering goes away then it is a sign Qt is using too much cpu. I haven't seen it doing anything weird related to CPU usage on my computer. But if gtk can behave in a different way in different machines the same probably happens to Qt too.
the behavior is pretty odd, with the deep filter enabled I am getting no stuttering consistently, only when i open discord voice settings or the kde tray audio menu. whether the window is open or closed seems to have no effect on the results, unless updating easy effects can change the quantum i doubt i've used anything different prior to the update.
whether the window is open or closed seems to have no effect on the results
So the "too slow" is not from the window putting stress on the CPU. Good.
unless updating easy effects can change the quantum
As far as I remember we build our pipeline the same way. PipeWire does change quantum when EasyEffects redirects apps. But that is something that has always happened.
This is my pw-top. The stutter problem still occuring, but somehow now it get back to sync on its own after a few second of video playback, although it also happen when playing videos from VLC.
And i have to point out, that playing only-audio files is smooth, without any problems. And i i have huge latency difference between versions 8.0+ and below 8.0
In my case, I'm running EE 8.0.3 on a Raspberry Pi5 with Debian OS. The biggest difference from EE 7.2.5 is the "CPU load". With 7.2.5, the load was around 25%, but with 8.0.3, it's 80% or more. What's strange is that with 7.2.5, turning DFN on increased the load by more than 10%, but with 8.0.3, there's no change in CPU load whether DFN is on or off.
In any case, the CPU load has increased so much with EE 8.0.3 that it's likely the cause of the increased latency.
I'm happy to help with testing to determine the cause of the increased CPU load. wwmm <-- If you give me specific instructions on how to investigate, I'll look into it. (^_^
wwmm <-- If you give me specific instructions on how to investigate, I'll look into it. (^_^
The first thing to do is measuring the cpu load when the window is closed and compare it to when the window is opened. I have the feeling that Qt cpu usage is abnormal in some users hardware. On my computer there is no relevant difference in CPU usage when compared to the old gtk branch.
Hey, I have written this off as "oh well I just won't use the deep noise suppression" in my prior mentioned case but this seems to be happening with the default noise suppression as well, albeit audio just cuts/chops a couple times as opposed to a more complete degradation.
I haven't tried increasing the quantum but you can probably see how this seems like an update related issue since it didn't happen before and my pipewire version stayed the same, there is no tangible difference in cpu usage in my case. I am not quite sure how to increase the quantum yet but I'll get back when I read up on it.
In the meantime I have updated to nobara 43 and the issue persists.
if you could point me towards any other things i could report that may help with pinning this down I'd be more than happy to comply. thank you for your work on this regardless, I wish I could be of more use.
@Aragxmi run pw-top and pay attention to the quantum (soundcard line) and busy column (plugins and soundcard lines). Are there significant differences at the moment the stuttering happens?
if by soundcard line you mean this, then no, there's no obvious difference to having noise suppression enabled/disabled, the wait and busy are about the same, i do see the err column go up for this line specifically only when stuttering occurs.
ee_soe_equalizer and ee_soe_limiter specifically also accumulate errors, but again I don't see anything out of the ordinary (baseline being with them off) other than that. ee_soe_output_level and ee_soe_spectrum also accumulate errors albeit slower and not exactly when stutters occur. with noise suppression off err doesn't increase, besides for plasmashell for some reason, which since starting this has accumulated 1032000ish in the err column.
the busy columns show an increase in nanoseconds from around 5 to 15 when speaking out loud but stuttering occurs regardless of whether i am speaking or not. (deep noise remover used as example on the last statement specifically).
I should probably also specify this is happening on an i9-13980hx with a power limit of 190w, not that it would reach that when processing audio but it seems somewhat relevant.
f by soundcard line you mean this, then no, there's no obvious difference to having noise suppression enabled/disabled, the wait and busy are about the same, i do see the err column go up for this line specifically only when stuttering occurs.
Yes. The only thing that could be related to stuttering is the quantum of 256. Some systems do not handle it well. Even if the cpu is powerful. This kind of thing also depends on the soundcard hardware and driver.
The fact it accumulates errors when the busy columns has low waiting values in the microseconds range is strange. I wonder if maybe PipeWire is not being able to set realtime priorities in your system. Does the output of
chrt -ap
pidof easyeffects
shows a rhread set to SCHED_RR ?
I am getting
chrt: invalid PID argument: 'easyeffects'
i should mention i have easyeffects installed as system flatpak.
anyway, i ran pidoff easyeffects and got 3247 out of it then ran
chrt -ap 3247 and got the following log where only 1 thread has SCHED_RR | SCHED_RESET_ON_FORK
chrt -ap 3247 and got the following log where only 1 thread has
SCHED_RR | SCHED_RESET_ON_FORK
Ok. So lack of realtime priorities is not the issue. Only the plugins thread should get it and that is happening.
so then increasing quantum remains my only option? I tried changing the default one from pipewire.conf but it seems it doesnt have any effect on the soundcard line... not quite sure what to do from here.
so then increasing quantum remains my only option? I tried changing the default one from pipewire.conf but it seems it doesnt have any effect on the soundcard line... not quite sure what to do from here.
You can temporarily force a fixed quantum value with the command
pw-metadata -n settings 0 clock.force-quantum 2048
. You can go up to 8192. Make sure to always select values that follow power of 2.
This kind of issue is among the hardest to solve because it often has different causes. But the fact you have a non zero error count suggests that increasing the quantum might help.
okay I am losing my mind, it seems that after a restart the default quantum is 512, but when i clicked to call my friend on discord it instantly changed it to 256, then i ran your command to force it to 2048, which worked and stayed that way even after discord call, it is definetly a quantum issue, 512 played audio perfectly as far as i can tell. still dont know what to do about discord having a say in my soundcard's quantum...
still dont know what to do about discord having a say in my soundcard's quantum...
What you are seeing will happen with other applications too. By default pipewire's dynamically switches latency so that the user has low latency when needed and high latency and as a result lower cpu usage when low latency is not needed. It decides that based on the latency value requested by the apps that are currently playing audio.
Discord probably requested a low latency value. And pipewire gave it to it. The problem is that for some reason your system is not being able to handle this when the extra load imposed by EasyEffects plugins is there.
Something you can do is launching Discord with the environment variable PULSE_LATENCY_MSEC set to something like PULSE_LATENCY_MSEC=60 or higher values. This way you do not have to force a fixed quantum value. What removes the advantages of dynamic latency.
I've been seeing video playback sync issues that match this description.
It turns out that the problem goes away if I turn off the inactivity timeout (Preferences > Audio > Enable inactivity timeout > off). Unfortunately, Easy Effects uses CPU all the time this way, but at least it's a small amount (~1% in top).
On the other hand, I can reproduce the problem more readily by turning on the inactivity timeout and setting it to a low value like 1s.
Forcing quantum values doesn't seem to fix it for me.
The audio always plays fine, by the way; it's the video that appears to stutter as it tries to sync. It's especially apparent with audio sync videos like this one.
It turns out that the problem goes away if I turn off the inactivity timeout (Preferences > Audio > Enable inactivity timeout > off). Unfortunately, Easy Effects uses CPU all the time this way, but at least it's a small amount (~1% in top).
Some plugins buffer data inside them. Forcing the pipeline to stay linked for more time and to play silence will remove this old data. But that by itself should not cause stuttering. You will listen to the old data and depending on how much old data there is see lack of sync between audio and video. Stuttering just because of that is strange.
Forcing the pipeline to stay linked for more time and to play silence will remove this old data. But that by itself should not cause stuttering.
To be clear, turning off the inactivity timeout doesn't cause stuttering - it fixes it (for me), or at least so it seems over the course of today.
To be clear, turning off the inactivity timeout doesn't cause stuttering - it fixes it (for me), or at least so it seems over the course of today.
Oh... I misunderstood your explanation. So rebuilding the pipeline is causing stuttering. Hum... We we do is asking pipewire to create the filter objects and then link them. Usually it handles this well. I wonder what is happening to it in this case.