Open tuxrinku opened 7 months ago
Just to confirm, the crackling only happens when running pipewire 1.0.4 on the liquorix kernel?
While the crackling is happening, what does pw-top
show, especially in the "ERR" column?
Yes that's it. But at the same time, the audio works fine on generic kernel, still on pipewire 1.0.4. So the problem is affecting the combo liquorix kernel + pipewire 1.0.4 + easyeffects.
Running pw-top while having some audio didn't show anything special. I have some processses that have something different than 0 in the ERR column tho. See the attached screenshot
While the ERR
column in pw-top can seem kind of vague, the vast majority of the time the ERR
counter is incremented because of an xrun. xruns are also usually the cause of "crackling", "pops", and "random clicks".
From the pw-top
manpage:
Xruns for drivers are when the graph did not complete a cycle. This can be because a node in the graph also has an Xrun. It can also be caused when scheduling delays cause a deadline to be missed, causing a hardware Xrun.
Xruns for followers are incremented when the node started processing but did not complete before the end of the graph cycle deadline.
Basically, for some reason the players with ERR values > 0 that you see in pw-top (easyeffects / alsa) were unable to finish processing in time, so you hear crackling. My guess is that liquorix is doing something to the realtime scheduling configuration of the kernel that doesn't play nicely with pipewire
Based on your pw-top image the audio players you are running are requesting a very low latency (quantum) value. Not all systems handle such a low quantum well. Take a look at https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Guide-Latency and try to see if forcing a fixed and higher latency makes any difference. Is the quantum this low in the configuration that does not have the crackling?
Changing quantum setting to 256 seems to be working. The configuration is the same when it doesnt have the crackling, just a different kernel. So basically quantum set at 64 with generic ubuntu kernel = no problem; quantum set at 64 with liquorix kernel = crackling audio. Both kernels are 6.8
So basically quantum set at 64 with generic ubuntu kernel = no problem; quantum set at 64 with liquorix kernel = crackling audio. Both kernels are 6.8
This is curious. I would expect a kernel customized for responsiveness like liquorix to handle low latency values better than a generic kernel.
Actually, I have a similar problem and would like to ask you a question. I have a USB-DAC connected to my Raspberry pi5 and I am listening to the sound processed by Easy Effects ('Input mode'). However, when I connect a particular USB-DAC, I hear a constant 'crackle' in the sound when I monitor it.
Since a smaller value for the 'Pipewire' server parameter Quantum may work around this problem, I opened '/usr/share/pipewire/pipewire.conf' and tried to change the Quantum size. However, after saving the settings and restarting Easy Effects, the Quantum size remains the same as before. Did I manipulate the contents of the wrong file?
I don't know if changing the quantum size can eliminate the "crackling" sound, but I wanted to comment because I don't know the cause and wanted to try different things. Does anyone have any ideas? I have 5 different USB DACs and 3 of them make the crackling sound.
If you are trying to eliminate crackling, you will want to increase the quantum value.
Additionally, after making changes to pipewire.conf
, you will at least need to log out and log back in again. Of course, the most guaranteed method is always to do a reboot.
You may also want to consider a hardware (manufacturing defect in the DAC) or power supply (poor filtering on the 5v supply to the rpi5, or other noisy usb devices connected to the same rpi5) problem. The first step to checking this would be to test the DAC on a different, known good computer.
Thanks for the advice. However, even though I increased the quantum value as follows, the “crackling” was still audible and had no effect. I think the cause is something else. default.clock.quantum = 2048 default.clock.min-quantum = 1024 default.clock.max-quantum = 4096
Thanks for the advice. However, even though I increased the quantum value as follows, the “crackling” was still audible and had no effect. I think the cause is something else. default.clock.quantum = 2048 default.clock.min-quantum = 1024 default.clock.max-quantum = 4096
This will increase the minimum possible value but PipeWire is still free to dynamically change the latency within the given range. In some cases it is the dynamic latency switching that causes crackling. Try to temporarily set a fixed quantum to see if this helps to fix the crackling https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Guide-Latency.
Thank you. I tried to force a change in the quantum value based on your advice. It is true that as the quantum value is increased (e.g., above 4096), the frequency of crackling tends to decrease. However, this does not mean that it disappears completely. Crackling can still be heard randomly from time to time. If the quantum is set to 4096 or higher, the sound delay becomes more pronounced, so this setting value is not practical.
It is important to note that this crackling sound does not occur when in “output” mode. For example, when I am listening to Youtube music via 'Easy Effects', the crackling does not occur. This problem only occurs when in “Input” mode. For example, if I connect a USB microphone and listen to the sound captured by the microphone, the crackling sound occurs.
This difference may be due to the difference in the sound processing process between the “input” and “output” modes, but I am not an expert and do not know for sure.
By the way, the Sound Blaster Play! 3, a cheap DAC available on Amazon.com for about $10, does not produce this crackling sound even when in “input” mode. However, more expensive DACs, this problem occurs. @_@ Hmmm, this is a mystery.
This difference may be due to the difference in the sound processing process between the “input” and “output” modes, but I am not an expert and do not know for sure.
Usually having an additional pipeline makes PipeWire switching to a different latency. The command pw-top
will show which quantum PipeWire is actually using.
By the way, the Sound Blaster Play! 3, a cheap DAC available on Amazon.com for about $10, does not produce this crackling sound even when in “input” mode. However, more expensive DACs, this problem occurs. @_@
This is a sign that something in the soundcard driver is not playing nice with PipeWire. Maybe using a different kernel version will help. Or selecting a different ALSA headroom
value in WirePlumber/PipeWire configuration files.
Thanks for your advice. I used the 'pw-top' command to check the actual quantum values used. As a result, the value of 'default.clock.quantum = xxx' set in 'pipewire.conf' was correctly reflected. i.e. when xxx was 512, the actual quantum value used was 512.
I hope someone has had a similar experience and solved the problem... This is the interim report for now. (^_^
I used the 'pw-top' command to check the actual quantum values used. As a result, the value of 'default.clock.quantum = xxx' set in 'pipewire.conf' was correctly reflected. i.e. when xxx was 512, the actual quantum value used was 512.
Did you run pw-top after executing the command that forces a fixed quantum? As you configuration file was before there is nothing forbidding PipeWire from changing the quantum on the fly. And this can cause crackling on some systems depending on the situation.
Thank you.
Did you run pw-top after executing the command that forces a fixed quantum? Yes, I tested it once again. As a matter of fact, as quantum values are increased, the frequency of crackling tends to decrease. The sound does not disappear completely, but the trend is certain.(Now I am using 512 as the quantum value)
In addition, today I discovered that one of the causes of the crackling is related to the add-on “Stereo Tools”. I use “Stereo Tools” when using a USB microphone. The reason is that USB microphone is mono-channel, so the sound only comes from the left side. Therefore, I selected “LR > L+R (mono total L+R)” in the “Stereo Matrix” function to get the same sound from the left and right headphones.
In fact, the crackling sound is at its worst when this selection is made. And when this is the case, “Deep Noise Remover” does not remove the noise. I think this is because the noise is generated outside of the effects process and cannot be removed. If I disable “Stereo Tools,” the crackling noise is reduced to about 1/5-1/10. The noise is not completely gone, but it is better than before. I hope someone will do a follow-up test to find the root cause and solve the problem. I can only help as a tester at the moment, though.
After that, I will report the facts I found as a memorandum. I tried clicking the "global bypass" button in the upper left of the screen.
As a result, I heard the crackling sound whether Global bypass was enabled or disabled. When it was enabled, the crackling sound became smaller, but the sound itself was still audible.
In other words, this crackling sound seems to be generated outside the functions of the various plug-ins of Easy Effects. It may be a compatibility issue between the audio driver and the DAC. That's all for additional information.
In other words, this crackling sound seems to be generated outside the functions of the various plug-ins of Easy Effects.
Crackling in global bypass mode are definitely generated outside of EasyEffects code. In this mode the pipeline is
player -> null-sink -> output_level -> spectrum -> soundcard
The null-sink is is provided by PipeWire. And the output level meter and spectrum plugins are always in passthrough mode. So a lower level issue in PipeWire or drivers is the most likely explanation.
EasyEffects Version
7.1.6
What package are you using?
Other (specify below)
Distribution
Ubuntu 24.04, using the package shipped with the distribution.
Describe the bug
I'm using Ubuntu 24.04 (coming from development release) but since then the audio has been crackling here and there. I'm using the liquorix kernel (6.8.7), but there was no problem at all with this kernel before the update to pipewire 1.0.4 that shipped with 24.04.
There is no problem with the regular ubuntu generic kernel. I don't have much experience debugging audio, and even less with pipewire itself
Expected Behavior
Audio is playing through easyeffects without any issue.
Debug Log
No response
Additional Information
No response