Sound stutter under cpu load when using DNR

[XSilverTH]

EasyEffects Version

7.1.6

What package are you using?

Arch (easyeffects)

Distribution

Archlinux

Describe the bug

i can hear stutters in (output) sound whenever using deep noise remover on my input device even if easyeffects isnt set to process output streams
this also happens in the flatpak version
whenever deep noise remover is turned on and i do something that uses the cpu (even just a little) the output stream instantly starts to stutter (opening tabs, playing games)
i also tested this with stress (on cpu) and the stutter only happened when 1. easyeffects was open. 2.deep noise remover was enabled (only on input. i cant really test if the same happens when dnr is enabled on output streams as it messes up music and stuff so i cant really hear if there is stuttering or not)

Expected Behavior

hear a completely normal and hq output stream no matter if cpu is under load or not

Debug Log

Debug Log

Paste your log here

Additional Information

No response

[violetmage]

Can you share the output of the pw-top command? The best would be to run the command, take screenshot, cause the audio stuttering, then take another screenshot.

Additionally, can you give any info about the input you are applying the deep noise remover too?

[wwmm]

whenever deep noise remover is turned on and i do something that uses the cpu (even just a little) the output stream instantly starts to stutter (opening tabs, playing games)

Usually a sign that the latency automatically selected by PipeWire is too low to handle the realtime processing EasyEffects has to do while putting additional load in the CPU. It is also common that the same setup works when EasyEffects is not running because audio players do not usually audio processing in a realtime thread. Once EE is there the pressure on the system becomes different. The output of pw-top should give a hint about what PipeWire is doing to the latency.

[XSilverTH]

(fsr github isnt letting me upload anything so i uploaded them somewhere else)
https://r2.e-z.host/538bbd19-61b7-4f8c-a489-5a614ec93546/7cvhy83m.png
easyeffects running with deep noise remover enabled and stress -c 24 running (causes the audio to completely stop at times and when it doesnt it barely plays)
https://r2.e-z.host/538bbd19-61b7-4f8c-a489-5a614ec93546/3udyxzfa.png
easyeffects running with deep noise remover enabled but doing nothing to stress the cpu (audio plays fine for the most part. you can hear some stuttering here and there)
https://r2.e-z.host/538bbd19-61b7-4f8c-a489-5a614ec93546/mhy2b3xk.png
easyeffects running with deep noise remover disabled and stress -c 24 running (completely solves the issue)

im applying dnr to my microphone i dont really know what you mean by info. its a normal headset microphone with alot of noise so i apply dnr to it to make it not sound like a jet engine

[wwmm]

(fsr github isnt letting me upload anything so i uploaded them somewhere else) https://r2.e-z.host/538bbd19-61b7-4f8c-a489-5a614ec93546/7cvhy83m.png easyeffects running with deep noise remover enabled and stress -c 24 running (causes the audio to completely stop at times and when it doesnt it barely plays) https://r2.e-z.host/538bbd19-61b7-4f8c-a489-5a614ec93546/3udyxzfa.png easyeffects running with deep noise remover enabled but doing nothing to stress the cpu (audio plays fine for the most part. you can hear some stuttering here and there) https://r2.e-z.host/538bbd19-61b7-4f8c-a489-5a614ec93546/mhy2b3xk.png easyeffects running with deep noise remover disabled and stress -c 24 running (completely solves the issue)

im applying dnr to my microphone i dont really know what you mean by info. its a normal headset microphone with alot of noise so i apply dnr to it to make it not sound like a jet engine

PipeWire is selecting a quantum size of 256. The quantum is related to the latency https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Guide-Latency. I often see systems that are not able to handle a quantum of 256 even the only relevant thing that the cpu is doing is playing audio. You probably will need to force a higher quantum when putting heavy load on your cpu and running EE at the same time.

[wwmm]

You probably will need to force a higher quantum when putting heavy load on your cpu and running EE at the same time.

Try something like 1024 or 2048. I think it can be any value between 32 and 8192 but power of 2 values are more efficient.

[XSilverTH]

2048 just changes how its behaves. it still stutters but in a different way. going higher makes it worse
while 1024 does reduce the amount of stutters it doesnt make it completely disappear it also makes some games run faster? (like 2x speed) i dont really know why that happens but it does
512 makes it alot better but still doesnt completely fix it. makes it so lighter loads dont stutter but heavy loads still stutter alot (and sometimes just crash easyeffects)

[XSilverTH]

also something else i found is that sometimes randomly when under load it stops stuttering but instead delays my input by like 4 seconds

[wwmm]

2048 just changes how its behaves. it still stutters but in a different way. going higher makes it worse while 1024 does reduce the amount of stutters it doesnt make it completely disappear it also makes some games run faster? (like 2x speed) i dont really know why that happens but it does 512 makes it alot better but still doesnt completely fix it. makes it so lighter loads dont stutter but heavy loads still stutter alot (and sometimes just crash easyeffects)

Maybe these games frame time is affected by the audio latency. I am not sure. But back to the original problem there isn't really something that can be done on our side. Some filters algorithms are heavier on resources than others. Depending on the combination of soundcard drivers + PipeWire + CPU + filters having audio effects and high CPU load on top of it won't work well.

There were cases in the past where users had some improvements by changing the kernel to another whose configuration was slightly different in regards to the audio latency. It is something to consider.

[XSilverTH]

i did try stable, zen and liquorix and there wasnt a difference (maybe there was but it was small enough for me to not notice)
my problem here is that the output is stuttering while the effects are on input. i rarely put effects on my output as i have separate hardware for that so i dont even want easyeffects to process them. i dont have a problem with my input stuttering when cpu is under load but i cant have my output just randomly stop because a game im playing decided to load a new region.

[wwmm]

i dont have a problem with my input stuttering when cpu is under load but i cant have my output just randomly stop because a game im playing decided to load a new region.

I'm confused now. EasyEffects is processing only your microphone and when the game is loading a new region there is no sound being outputed to the soundcard? Is the mic audio still going where it should in this case?

[XSilverTH]

i used game loading a new region as an example what i meant is that on easyeffects, proccess all output streams is disabled and there is no effect on output. there is only a dnr effect on my input and nothing else. my input is fine its my output thats stuttering (and when the load is really heavy stops completely and crashes easyeffects)

[wwmm]

i used game loading a new region as an example what i meant is that on easyeffects, proccess all output streams is disabled and there is no effect on output. there is only a dnr effect on my input and nothing else. my input is fine its my output thats stuttering (and when the load is really heavy stops completely and crashes easyeffects)

Ok. I've looked at your pw-top output again and the error count is quite high. Most of the time those errors are what is called xrun It is rarely possible to fix them on the client side. In some cases people are able to reduce xrun errors tuning a parameter called ALSA headroom. It can be adjusted in PipeWire's or WirePlumber's configuration files if I am not mistaken. It may be worth to try.

[XSilverTH]

im not sure if i did this correctly i just followed https://wiki.archlinux.org/title/PipeWire#Audio_cutting_out_when_multiple_streams_start_playing
it made no difference

[XSilverTH]

btw i remember using this exact setup a few months ago with no issues so i thought maybe this was just something that a new update of some app caused but it doesnt look like it

[wwmm]

btw i remember using this exact setup a few months ago with no issues so i thought maybe this was just something that a new update of some app caused but it doesnt look like it

At least on our side there was no update in the last months that would justify stuttering being introduced in this situation. Maybe something in PipeWire has changed.