wwmm
crackling issues on arch
EasyEffects Version
latest
What package are you using?
Arch (easyeffects)
Distribution
Endeavouros and Cachyos
Describe the bug
I have noticed that even with no effects applied, having easyeffects on causes crackling audio and errors (in the ERR column) in pw-top. interestingly, crackling only occurs when an audio starts or stops playing, and that is when errors increase as well, usually in 3 or 4 waves of ten errors in one iteration. lowering quantum values makes things even worse, while increasing them doesn't really help.
Expected Behavior
no issues, at least with no effects
Debug Log
No response
Additional Information
i was first on endevaouros, which made me think i broke some configuration or setting, so i switched to cachyos, only to encounter the same issue there as well. i was also able to reproduce the issue on a stock cachyos installation as well, and i couldn't get the unupdated live iso to reproduce the issue then. this made me think this is caused by some other package which gets updated and breaks things, so i even attempted to update packages in a binary search like manner, and although the issue popped up after i updated four packages toward the end (nfs-utils nfsidmap noto-fonts noto-fonts-emoji), installing these on their own on a fresh live iso did not reproduce the error again. this computer has an i7-10750H, 16 gbs of ram and an rtx 3060. i use it with hdmi, however the issue also persists if i boot without the hdmi connection and headphones connected to the laptop itself.
additionally, i have another setup (i5-4440, gtx 1060, and 8 gbs of ram), which i also had endeavouros in. i confirmed that prior to running pacman -Syu, no crackling or pw-top errors were present, however after running the full system update, the issues started appearing on that computer as well.
By latest package do you mean the Qt port in our master branch or the last gtk4 release?
By latest package do you mean the Qt port in our master branch or the last gtk4 release?
oh sorry i did not know the distinction. i installed it with pacman (pacman -S easyeffects), it is version 7.2.5. i also tried the aur build listed on the wiki, which had the same issue.
Same to me, but it's randomly happening as I stated in #4085. Can you try to downgrade pipewire to test if the crackling sound occurs?
Same to me, but it's randomly happening as I stated in #4085. Can you try to downgrade pipewire to test if the crackling sound occurs?
i have downgraded these packages: gst-plugin-pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-audio-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-pulse-1_1.4.7-1-x86_64.pkg.tar.zst libpipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-alsa-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-jack-1_1.4.7-1-x86_64.pkg.tar.zst
and the issue is actually gone, which is weird, because when i updated these packages when i was trying to detect the packages causing the problem, it did not happen immediately. hope this will help with understanding what is wrong though
i have downgraded these packages: gst-plugin-pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-audio-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-pulse-1_1.4.7-1-x86_64.pkg.tar.zst libpipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-alsa-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-jack-1_1.4.7-1-x86_64.pkg.tar.zst
and the issue is actually gone, which is weird, because when i updated these packages when i was trying to detect the packages causing the problem, it did not happen immediately. hope this will help with understanding what is wrong though
Are you sure? I did the same, but it's still happening.
i have downgraded these packages: gst-plugin-pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-audio-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-pulse-1_1.4.7-1-x86_64.pkg.tar.zst libpipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-alsa-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-jack-1_1.4.7-1-x86_64.pkg.tar.zst and the issue is actually gone, which is weird, because when i updated these packages when i was trying to detect the packages causing the problem, it did not happen immediately. hope this will help with understanding what is wrong though
Are you sure? I made the same, but it's still happening.
yes, i verified in both cachyos and endevaouros, at least i do not feel any extra crackling and pw-top errors have stopped. furthermore what is weirder is i actually had these files around because i remember downgrading yesterday, except the gst plugin, which pacman requested as a dependency today. i remember the downgrade having no effect yesterday, but seemingly it shouldnt have allowed me to downgrade in the first place, maybe my memory serves me wrong and i never downgraded at all.
i am not super knowledgeable on these details, but maybe you can try the endeavouros live iso, which uses packages from march. in there connect to the internet and only execute pacman -Sy and pacman -S easyeffects to see if the issues persist to rule out hardware issues
i have downgraded these packages: gst-plugin-pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-audio-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-pulse-1_1.4.7-1-x86_64.pkg.tar.zst libpipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-alsa-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-jack-1_1.4.7-1-x86_64.pkg.tar.zst
We stopped using gstreamer a few years ago. So its packages should not have any impact on us.
maybe my memory serves me wrong and i never downgraded at all.
Or maybe you did but forgot to reboot the computer. Or at least doing a logout to force a pipewire restart.
i have downgraded these packages: gst-plugin-pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-audio-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-pulse-1_1.4.7-1-x86_64.pkg.tar.zst libpipewire-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-alsa-1_1.4.7-1-x86_64.pkg.tar.zst pipewire-jack-1_1.4.7-1-x86_64.pkg.tar.zst
We stopped using gstreamer a few years ago. So its packages should not have any impact on us.
maybe my memory serves me wrong and i never downgraded at all.
Or maybe you did but forgot to reboot the computer. Or at least doing a logout to force a pipewire restart.
right, as i was using cachy live iso then, i could not reboot as it would erase everything. i logged in and out to test things, and i was able to trigger the problem like this. though, pacman shouldnt have allowed me to downgrade without gstreamer the day before, so it is confusing all around. i hope it is in some way helpful to solve this problem though, downgrading to july packages with easyeffects 7.2.5 solves the issues.
Can confirm, I'm having the same issue since few days back. Here are the package versions I'm on
easyeffects 7.2.5-1.1
pipewire 1:1.4.8-2.1
pipewire-alsa 1:1.4.8-2.1
pipewire-audio 1:1.4.8-2.1
pipewire-pulse 1:1.4.8-2.1
Crackling happens even with no plugins, and right after pausing a song/video. Noticeably only when easyeffects is running. There's no effect on increasing min-quantum even to 2048.
Same problem on Fedora 42 using DNF. But I tried Flatpak, and it seemed that EE worked well. No crackling.
I am experiencing the same issue on Fedora 43.
What I tried to do so far:
- add threadirqs as a kernel command
- min-quantum to 512 or 1024
- rt.prio = 88
And no luck. Without easy effects, everything is alright. With easyeffects, there is a lot of cracking.
Experience the same issue on Fedora 42 running the latest Flatpak. Crackling only happens when starting or stopping the audio, feels random when it happens.
Experience the same issue on Fedora 42 running the latest Flatpak. Crackling only happens when starting or stopping the audio, feels random when it happens.
Run the command chrt -ap pid where pid is EasyEffects process pid number. Is SCHED_RR preset in the output? Until a few weeks ago a xdg-desktop-portal bug was not allowing PipeWire to set realtime priorities to the plugins thread. Maybe that is what is happening to you.
It just says SCHED_OTHER /BATCH
miroslav@fedora:~$ chrt -ap 74902 pid 74902's current scheduling policy: SCHED_OTHER pid 74902's current scheduling priority: 0 pid 74902's current runtime parameter: 2100000 pid 74911's current scheduling policy: SCHED_OTHER pid 74911's current scheduling priority: 0 pid 74911's current runtime parameter: 2100000 pid 74912's current scheduling policy: SCHED_OTHER pid 74912's current scheduling priority: 0 pid 74912's current runtime parameter: 2100000 pid 74914's current scheduling policy: SCHED_OTHER pid 74914's current scheduling priority: 0 pid 74914's current runtime parameter: 2100000 pid 74915's current scheduling policy: SCHED_OTHER pid 74915's current scheduling priority: 0 pid 74915's current runtime parameter: 2100000 pid 75189's current scheduling policy: SCHED_OTHER pid 75189's current scheduling priority: 0 pid 75189's current runtime parameter: 2100000 pid 75191's current scheduling policy: SCHED_OTHER pid 75191's current scheduling priority: 0 pid 75191's current runtime parameter: 2100000 pid 75192's current scheduling policy: SCHED_OTHER pid 75192's current scheduling priority: 0 pid 75192's current runtime parameter: 2100000 pid 75998's current scheduling policy: SCHED_OTHER pid 75998's current scheduling priority: 0 pid 75998's current runtime parameter: 2100000 pid 76265's current scheduling policy: SCHED_BATCH pid 76265's current scheduling priority: 0 pid 76265's current runtime parameter: 2100000 pid 76267's current scheduling policy: SCHED_BATCH pid 76267's current scheduling priority: 0 pid 76267's current runtime parameter: 2100000 pid 76268's current scheduling policy: SCHED_BATCH pid 76268's current scheduling priority: 0 pid 76268's current runtime parameter: 2100000 pid 76269's current scheduling policy: SCHED_BATCH pid 76269's current scheduling priority: 0 pid 76269's current runtime parameter: 2100000 pid 76270's current scheduling policy: SCHED_BATCH pid 76270's current scheduling priority: 0 pid 76270's current runtime parameter: 2100000
It just says SCHED_OTHER /BATCH
Then you still have the xdg-desktop-portal version with the bug that is not allowing realtime priorities to be set by pipewire. Although crackling can still happen even with realtime priorities in the plugins thread not having them definitely does not help.
a majority of the crackling is gone with the pipewire update a month ago, however i now get "pops" occasionally when audio starts or stops now. this is not present without easyeffects.
I have this issue on a upgraded Arch system (as of yesterday). I do have some EE tasks on the SCHED_RR class:
pid 302604's current scheduling policy: SCHED_OTHER pid 302604's current scheduling priority: 0 pid 302604's current runtime parameter: 1600000 pid 302605's current scheduling policy: SCHED_OTHER pid 302605's current scheduling priority: 0 pid 302605's current runtime parameter: 1600000 pid 302606's current scheduling policy: SCHED_OTHER pid 302606's current scheduling priority: 0 pid 302606's current runtime parameter: 1600000 pid 302607's current scheduling policy: SCHED_OTHER pid 302607's current scheduling priority: 0 pid 302607's current runtime parameter: 1600000 pid 302608's current scheduling policy: SCHED_OTHER pid 302608's current scheduling priority: 0 pid 302608's current runtime parameter: 1600000 pid 302609's current scheduling policy: SCHED_OTHER pid 302609's current scheduling priority: 0 pid 302609's current runtime parameter: 1600000 pid 302611's current scheduling policy: SCHED_OTHER pid 302611's current scheduling priority: 0 pid 302611's current runtime parameter: 1600000 pid 302612's current scheduling policy: SCHED_OTHER pid 302612's current scheduling priority: 0 pid 302612's current runtime parameter: 1600000 pid 302613's current scheduling policy: SCHED_RR|SCHED_RESET_ON_FORK pid 302613's current scheduling priority: 20 pid 302616's current scheduling policy: SCHED_OTHER pid 302616's current scheduling priority: 0 pid 302616's current runtime parameter: 1600000 pid 302623's current scheduling policy: SCHED_BATCH pid 302623's current scheduling priority: 0 pid 302623's current runtime parameter: 1600000 pid 302624's current scheduling policy: SCHED_BATCH pid 302624's current scheduling priority: 0 pid 302624's current runtime parameter: 1600000 pid 302625's current scheduling policy: SCHED_BATCH pid 302625's current scheduling priority: 0 pid 302625's current runtime parameter: 1600000 pid 302626's current scheduling policy: SCHED_BATCH pid 302626's current scheduling priority: 0 pid 302626's current runtime parameter: 1600000 pid 302627's current scheduling policy: SCHED_BATCH pid 302627's current scheduling priority: 0 pid 302627's current runtime parameter: 1600000 pid 302628's current scheduling policy: SCHED_BATCH pid 302628's current scheduling priority: 0 pid 302628's current runtime parameter: 1600000 pid 302629's current scheduling policy: SCHED_BATCH pid 302629's current scheduling priority: 0 pid 302629's current runtime parameter: 1600000
But the issue still persists with lots of error on the Alsa output:
pw-top -b -n 2
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
C 30 0 0 --- --- --- --- 0 Dummy-Driver
C 31 0 0 --- --- --- --- 0 Freewheel-Driver
C 36 0 0 --- --- --- --- 0 effect_input.virtual-surround-7.1-hesuvi
C 37 0 0 --- --- --- --- 0 effect_output.virtual-surround-7.1-hesuvi
C 65 0 0 --- --- --- --- 0 Midi-Bridge
C 68 0 0 --- --- --- --- 0 bluez_midi.server
C 73 0 0 --- --- --- --- 0 alsa_output.pci-0000_12_00.1.pro-output-3
C 74 0 0 --- --- --- --- 0 alsa_output.pci-0000_12_00.1.pro-output-7
C 75 0 0 --- --- --- --- 0 alsa_output.pci-0000_12_00.1.pro-output-8
C 76 0 0 --- --- --- --- 0 alsa_output.pci-0000_12_00.1.pro-output-9
C 154 0 0 --- --- --- --- 0 v4l2_input._sys_devices_virtual_video4linux_video2
C 147 0 0 --- --- --- --- 0 alsa_output.pci-0000_12_00.6.analog-stereo
C 222 0 0 --- --- --- --- 0 alsa_input.pci-0000_12_00.6.analog-stereo
C 326 0 0 --- --- --- --- 0 Rhythmbox
C 320 0 0 --- --- --- --- 0 alsa_output.pci-0000_03_00.1.hdmi-stereo
C 323 0 0 --- --- --- --- 0 Dune: Awakening
C 224 0 0 --- --- --- --- 0 Dune: Awakening
C 303 0 0 --- --- --- --- 0 Dune: Awakening
C 302 0 0 --- --- --- --- 0 Dune: Awakening
C 294 0 0 --- --- --- --- 0 easyeffects_sink
C 204 0 0 --- --- --- --- 0 easyeffects_source
C 182 0 0 --- --- --- --- 0 ee_soe_output_level
C 202 0 0 --- --- --- --- 0 ee_soe_spectrum
C 230 0 0 --- --- --- --- 0 ee_sie_output_level
C 247 0 0 --- --- --- --- 0 ee_sie_spectrum
C 311 0 0 --- --- --- --- 0 ee_sie_rnnoise
C 284 0 0 --- --- --- --- 0 ee_sie_echo_canceller
C 291 0 0 --- --- --- --- 0 ee_sie_autogain
C 314 0 0 --- --- --- --- 0 ee_test_signals
C 250 0 0 --- --- --- --- 0 ee_soe_gate
C 242 0 0 --- --- --- --- 0 ee_soe_compressor
C 269 0 0 --- --- --- --- 0 ee_soe_multiband_compressor
C 244 0 0 --- --- --- --- 0 ee_soe_equalizer
C 237 0 0 --- --- --- --- 0 ee_soe_stereo_tools
C 262 0 0 --- --- --- --- 0 ee_soe_limiter
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
I 30 0 0 0,0us 0,0us ??? ??? 0 Dummy-Driver
S 31 0 0 --- --- --- --- 0 Freewheel-Driver
S 65 0 0 --- --- --- --- 0 Midi-Bridge
S 68 0 0 --- --- --- --- 0 bluez_midi.server
R 73 256 48000 609,8us 10,1us 0,11 0,00 0 S32LE 8 48000 alsa_output.pci-0000_12_00.1.pro-output-3
R 36 0 0 14,0us 7,1us 0,00 0,00 0 F32P 8 0 + effect_input.virtual-surround-7.1-hesuvi
R 37 0 0 1,2us 53,1us 0,00 0,01 0 F32P 2 0 + effect_output.virtual-surround-7.1-hesuvi
R 147 0 0 7,6us 17,6us 0,00 0,00 39954 S32LE 2 48000 + alsa_output.pci-0000_12_00.6.analog-stereo
R 323 256 48000 36,4us 3,5us 0,01 0,00 0 F32LE 2 48000 + Dune: Awakening
R 224 256 48000 17,5us 13,2us 0,00 0,00 0 F32LE 2 48000 + Dune: Awakening
R 303 256 48000 31,6us 4,3us 0,01 0,00 0 S16LE 2 48000 + Dune: Awakening
R 302 480 48000 4,6us 5,8us 0,00 0,00 0 S16LE 2 48000 + Dune: Awakening
R 294 0 0 1,3us 7,1us 0,00 0,00 0 F32P 2 48000 + easyeffects_sink
R 204 0 0 3,6us 6,2us 0,00 0,00 0 F32P 2 48000 + easyeffects_source
R 182 0 0 1,6us 6,1us 0,00 0,00 0 + ee_soe_output_level
R 202 0 0 2,2us 14,2us 0,00 0,00 0 + ee_soe_spectrum
R 230 0 0 1,5us 3,3us 0,00 0,00 0 + ee_sie_output_level
R 247 0 0 1,4us 10,6us 0,00 0,00 0 + ee_sie_spectrum
R 311 0 0 1,5us 72,4us 0,00 0,01 0 + ee_sie_rnnoise
R 284 0 0 3,8us 8,1us 0,00 0,00 0 + ee_sie_echo_canceller
R 291 0 0 1,3us 2,5us 0,00 0,00 0 + ee_sie_autogain
R 250 0 0 8,0us 65,4us 0,00 0,01 0 + ee_soe_gate
R 242 0 0 3,7us 29,1us 0,00 0,01 0 + ee_soe_compressor
R 269 0 0 1,9us 94,0us 0,00 0,02 0 + ee_soe_multiband_compressor
R 244 0 0 1,6us 74,2us 0,00 0,01 0 + ee_soe_equalizer
R 237 0 0 9,3us 23,0us 0,00 0,00 0 + ee_soe_stereo_tools
R 262 0 0 1,6us 33,9us 0,00 0,01 0 + ee_soe_limiter
S 74 0 0 --- --- --- --- 0 alsa_output.pci-0000_12_00.1.pro-output-7
S 75 0 0 --- --- --- --- 0 alsa_output.pci-0000_12_00.1.pro-output-8
S 76 0 0 --- --- --- --- 0 alsa_output.pci-0000_12_00.1.pro-output-9
S 154 0 0 --- --- --- --- 0 v4l2_input._sys_devices_virtual_video4linux_video2
S 222 0 0 --- --- --- --- 0 alsa_input.pci-0000_12_00.6.analog-stereo
I 326 0 0 0,0us 0,0us ??? ??? 0 S16LE 2 44100 Rhythmbox
S 320 0 0 --- --- --- --- 0 alsa_output.pci-0000_03_00.1.hdmi-stereo
S 314 0 0 --- --- --- --- 0 ee_test_signals
If I close EE, the crackling stops. It often happens whenever a game starts or with seemingly high CPU spikes. It may or may not last, as some times it stops after a moment, usually after the game is fully running and CPU usage has seemingly calmed down.
It also stops if I change the profile of the output in KDE's sound config. After that, relaunching EE and switching out / in the correct output again fixes the issue, all the while never needing to actually stop or restart any app or Pipewire itself.
Ofc, I've played with magic quantum settings all over the Internet to no avail.
Ofc, I've played with magic quantum settings all over the Internet to no avail.
Which values did you try? I see in your pw-top output 256 at the soundcard line. And when games are running they usually request a latency value that makes PipeWire switch to a quantum of 128. Some systems handle these values well. Others not so much.
Ofc, I've played with magic quantum settings all over the Internet to no avail.
Which values did you try? I see in your pw-top output 256 at the soundcard line. And when games are running they usually request a latency value that makes PipeWire switch to a quantum of 128. Some systems handle these values well. Others not so much.
Actually when recording this issue and now that's happening at this very moment again, I can attest my min quantum IS 128:
$cat ~/.config/pipewire/pipewire.conf.d/pipewire.conf
context.properties = { # top-level dictionary section
default.clock.rate = 48000
default.clock.allowed-rates = [ 44100 48000 ]
# default.clock.min-quantum = 512
default.clock.min-quantum = 128
}
Actually when recording this issue and now that's happening at this very moment again, I can attest my min quantum IS 128:
Although my system can handle this low latency value I usually launch games with PULSE_LATENCY_MSEC=60 to make PipeWire to select a higher latency. Nothing I play needs a latency this low.