Sporadic audio crackling

[Exioncore]

EasyEffects Version

0.3.52 (Built from the repo on 11 June 2022, Commit: acc11ae080a15d25ce32671d8e0f20a64d675a46)

What package are you using?

Other (specify below)

Distribution

Fedora 36

Describe the bug

The audio will sporadically crackles. Easiest way to trigger it is just simply listening to Youtube and either clicking on the Fedora Audio device selector from the task bar OR receiving a Discord notification, Either one of the two ALWAYS causes the audio to crackle.

The effects I am running are Autogain, Bass Enhancer, Bass Loudness and Crystalizer.

Things I have tried so far to solve the issue is following these instructions here to no avail: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning I created the file /etc/security/limits.d/95-pipewire.conf with the contents at the link as well as modified the file /usr/lib/systemd/system/rtkit-daemon.service and the file /etc/sysconfig/rtkit again as instructed at the link.

My question is, how can I further tweak either one of those files or, what else can I do to solve this crackling issue? I am fairly new to using Linux and so I don't quite know what to touch (does the file /etc/security/limits.d/95-pipewire.conf even matter if I do have rtkit running for instance?)

This is what htop says about the priorities: https://i.imgur.com/KALa8Dt.jpg

Please let me know if you need any additional information and how to collect it.

Main System Specs: AMD Ryzen 9 5900x Focusrite Scarlett Solo Arctis Pro Wireless

Expected Behavior

No crackling

Debug Log

Debug Log

Paste your log here

Additional Information

No response

[wwmm]

My question is, how can I further tweak either one of those files or, what else can I do to solve this crackling issue?

The first thing to do in these situations is verifying if the crackling is happening when a specific plugin is used. In this case I am thinking about the crystalizer. It is a very heavy plugin and it has to do some buffering. So there is a chance a crackling happens when PipeWire changes latency on the fly.

Through the command pw-top you can try to see if the latency is changing at the same time the crackling happens. The QUANT and the RATE columns are the ones you want to look at.

[wwmm]

Easiest way to trigger it is just simply listening to Youtube and either clicking on the Fedora Audio device selector from the task bar OR receiving a Discord notification

Discord's app is an endless source of problems. But I am not aware of this Fedora Audio device selector. Changing devices in PAvucontrol causes a crackling?

[wwmm]

You can try to temporarily set a fixed latency following the quantum range section at https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#quantum-ranges

[Exioncore]

Easiest way to trigger it is just simply listening to Youtube and either clicking on the Fedora Audio device selector from the task bar OR receiving a Discord notification

Discord's app is an endless source of problems. But I am not aware of this Fedora Audio device selector. Changing devices in PAvucontrol causes a crackling?

I mean this panel here, just simply bringing it up always causes a crackle:

Steam notifications also will cause a crackle from time to time. In the meantime I will try your suggestion and report back.

[Digitalone1]

That's the volume panel from Plasma, right? I suppose the issue comes from them and how they pick all the streams. Do you hear the same crackling also opening pavucontrol?

[Exioncore]

After using it for some time, it would seem that indeed setting a fixed quantum rate reduces a lot the number of times I get a crackle. It also crackles every time I do change the quantum rate or that I do see it change just like you suspected. The Crystalizer also seems to be the main culprit for it.

For the volume panel that is Plasma indeed. It is worth mentioning that when I open that panel I see a whole bunch of things happening via pw-top including changing quantum rates. Dunno about pavucontrol, I don't seem to have that.

[wwmm]

The Crystalizer also seems to be the main culprit for it.

I was expecting this because the code I implemented on it to handle some of the small buffering it needs to do is not as good as I would like yet. But with the other plugins this kind of thing should not be happening. Specially in the ones that use the LV2 standard. If you remove all the plugins from the pipeline is there still crackling? In this situation EasyEffects will be in passthrough mode

audio player -> EasyEffects Sink -> output level meter -> spectrum -> soundcard

As our virtual sinks are just an ordinary PipeWire null sink your audio buffers would be passing mostly through PipeWire code. And the output level meter and the spectrum do not change data.

[HarmfulBreeze]

I can confirm the issue and reproduce the "crackling" by switching between clock.force-quantum = 1024 and clock.force-quantum = 8192 with just the Convolver. However, I can not reproduce it after removing all plugins.

[dev-rfc]

It's the Crystallizer plugin,. I have the same issue, but it's gone when I disable that plugin.

[HarmfulBreeze]

It's the Crystallizer plugin,. I have the same issue, but it's gone when I disable that plugin.

It's probably not just Crystallizer, I haven't used it personally.

[d3vilguard]

As I see no work being done here - this has been a bug that I have had for years now. Doesn't matter the DE (KDE and Gnome), distro doesn't matter (Arch, Fedora, Tumbleweed). Notifications always begin with a crack. Sound starting is always delayed.

[wwmm]

As I see no work being done here - this has been a bug that I have had for years now. Doesn't matter the DE (KDE and Gnome), distro doesn't matter (Arch, Fedora, Tumbleweed). Notifications always begin with a crack. Sound starting is always delayed.

I suspect this bug's source is more complex than I thought. Initially I thought that the shortcomings of the convolver and crystalizer code were the only reason for it. But I use these plugins regularly and somehow I never hear crackling on my system. I admit sound notifications are not something that happens often on my computer. But I would expect the crackling to happen at some point along these years but somehow it doesn't. So something more complex is causing this bug.

[d3vilguard]

@wwmm I did have convolver but it's not it. KDE was crackling so much. Remembered this sauce. Currently testing it, seems ok for now? So might be actually a general pipewire bug and have nothing to do with easyeffects.

Niklāvs Koļesņikovs @pinkflames While I can't promise this will help, please try creating either /etc/pipewire/pipewire.conf.d/sample-rates.conf or $HOME/.config/pipewire/pipewire.conf.d/sample-rates.conf and put in it this:

context.properties = {
    default.clock.allowed-rates  = [ 48000 ]
}

Then restart the daemons with: systemctl --user restart pipewire{,-pulse}.socket and retest. If it no longer crackles, the reason for it was either use of 44.1 kHz sample rate or the transition itself. If the issue persists, you can try checking cat /proc/asound/card*/*/*/hw_params while audio is playing to see if it's correctly applied and reporting rate: 48000 (48000/1).

[wwmm]

@wwmm I did have convolver but it's not it. KDE was crackling so much. Remembered this sauce. Currently testing it, seems ok for now? So might be actually a general pipewire bug and have nothing to do with easyeffects.

Niklāvs Koļesņikovs @pinkflames While I can't promise this will help, please try creating either /etc/pipewire/pipewire.conf.d/sample-rates.conf or $HOME/.config/pipewire/pipewire.conf.d/sample-rates.conf and put in it this:

context.properties = {
    default.clock.allowed-rates  = [ 48000 ]
}

Then restart the daemons with: systemctl --user restart pipewire{,-pulse}.socket and retest. If it no longer crackles, the reason for it was either use of 44.1 kHz sample rate or the transition itself. If the issue persists, you can try checking cat /proc/asound/card*/*/*/hw_params while audio is playing to see if it's correctly applied and reporting rate: 48000 (48000/1).

This is forcing PipeWire to do the same sampling rate all the time instead of trying to avoid resampling. But If I am not mistaken this should be its default behavior. WE have to put more than one rate value in that array for it to try to change rate on the fly. I do this. But unless you were also doing the same it is strange this configuration is fixing anything.

[d3vilguard]

Unless Arch missing pipewire configuration I have no idea, but had the issue on Tumbleweed way back. KDE has a little sound feedback when you change volume. Very frequently if I were doing nothing and change volume it will play the sound while crackling, or playbacks with start with crackling for a moment. Now I do have to test if for a few days before saying that locking the sampling value fixes it. Linux audio has been a very big hit and miss. I sincerely enjoy being able to do my EQ with easyeffects. Would be awesome if I figure out why BT devices when left on idle for some time refuse to play audio and need to be reconnected.