Dear Maintainer, Starting around July or August 2024 I started getting routine but mild crackling out of my speakers. This lasted for several weeks and then went away on it's own. Starting around two weeks ago (approximately September 10, 2024) the crackling returned with a vengence. The most recent symptoms include anything from very mild crackling every few minutes to heavy crackling occuring constantly. Some times the crackling begins immediately upon rebooting my system or restarting pipewire-pulse and some times it can take up to 12 hours for crackling to occur. There is a correlation between system load and how frequently the crackling shows up and how severe the crackling is. During my testing today I used this command to place my system under load resulting in load averages around 40 and most of the CPU time being spent in the kernel: while true; do echo loop; (find /usr -type f | xargs -P 500 -I % -exec cat "%") I've experienced this crackling with: * Firefox ESR from apt * VLC from apt * Telegram when playing audio notifications, installed from apt * Foobar2000 running under wine-devel from apt * Skyrim running under Proton experimental from Steam * REAPER with Jack Audio output selected using pipewire-jack as the audio backend The problem does not appear to occur when using REAPER with ALSA selected as the audio backend. As well REAPER using jackd2 from apt does not appear to have this problem. I've been unable to confirm that VLC when using the ALSA backend does not crackle as VLC fails to open the ALSA audio device when I try. In general it has been challenging to find other programs to do more extensive testing because so much stuff now assumes PulseAudio will be available. REAPER in ALSA mode runs itself using realtime scheduling priority. Jackd2 is also running with realtime scheduling priority. As best I can tell pipewire and pipewire-pulse should be running itself with realtime scheduling priority but I don't know how to confirm this is actually happening. REAPER using ALSA and jackd2 delivers reliable audio during my testing even when I experience X GUI pauses exceeding several seconds. REAPER using pulsewire-jack and the other applications using pipewire-pulse will start crackling even when there is no appreciable load on the system. When running the find/xargs load generator the applications using pipewire-pulse and REAPER using pipewire-jack go into extreme levels of crackling to severe distortion. I've used the same media playing inside Firefox, VLC and REAPER to ensure the audio crackling is not present in the source material. As well at this point I'm fairly confident the bug does not originate with the kernel since REAPER using ALSA and jack2 has proven reliable. However I have tested different stable kernel releases and the backports kernel and there appears to be some correlation to kernel releases in the stable branch. Using the backports kernel (6.10 series at this time) does not appear to change the behavior at all compared to the 6.1.0-25-amd64 kernel build from stable. Likewise, using 6.1.0-23-amd64 does not appear to change the behavior. In my testing today using 6.1.0-17-amd64 resulted in much worse audio crackling that the beforementioned kernels. But then also 6.1.0-17-amd64 would have been the kernel I was using in the past well before I ever experienced the audio crackling. I'm pretty sure when I was running 6.1.0-17-amd64 and did not experience the crackling issue I was also using pipewire from backports however I've been unable to confirm this from the apt logs as they do not appear to have timestamps for the log entries. Usually, but not not always, I am able to temporarily resolve the crackling issue by running "systemctl --user restart pipewire-pulse" - specifically, earlier today when the crackling was very bad and very frequent doing the restarts did not help at all. At this moment, about 8 hours later, the audio crackling from Firefox is light and infrequent, and I just performed a restart and it has not resolved the issue. I have previously tried increasing the pipewire quantum to 8192 in an effort to prevent the crackling but it does not appear to have any effect at all. My first change was by running "pw-metadata -n settings 0 clock.quantum 8192" and later I modified the default pipewire.conf to set default.clock.quantum and default.clock.max-quantum to 8192 and that also did not seem to have any effect. I'm not sure what else I can do to test this, issolate the fault, or try to resolve the issue. If you have any thoughts please let me know. This issue is fairly annoying as my workstation's most frequent use case is for playing or editing multimedia.
Hello, I've got some additional info to report with my problem. First, as a status update, nothing has significantly changed for me. I'm still getting usually infrequent and light crackling and at times very frequent and heavy crackling. I've not been able to identify what variable is in play here. Second, I have another possible temporary workaround. This is tricky because of the intermittent nature of the problem but it does appear that in addition to restarting the pipewire-pulse process that restarting an individual application suffering from audio crackling can also temporarily resolve the crackling issue though it may take a few restarts in a row to get there. Third, I realized that way I listed the source of the builds for the packages I've experienced the issue with was non-optimal. Here is a less ambiguous report of packages and where they came from: - stable: firefox-esr, vlc, jackd2, linux-image-amd64 - stable-backports: pipewire, telegram-desktop - winehq: wine-devel (Wine project official Debian builds) Considering REAPER, wine-devel, and Proton Experimental are software that is compiled outside of the Debian build system, or in the case of REAPER and Proton Experimental I suspect without any Debian specific build process or helpers at all, I think this demonstrates that the audio clients themselves are not the problem for any Debian specific reason. I also know of another user running Debian 12 that is suffering from the same intermittent crackling issue. His problem showed up about 3 weeks ago but otherwise his description of the issue sounds just like mine: intermittent, sometimes light, sometimes heavy. though he has more luck with getting the problem to stay away by running an older kernel build (linux-image-amd64-22 as I recall). Possibly related, I also know another user that is running Ubuntu 18.06 who said they started experiencing audio crackling also around the same time I did. I checked with them and they are using PulseAudio and not pipewire. On one hand this appears to be kernel related but on the other hand, for myself personally, I am not experiencing any audio issues when applications are using the ALSA interface themselves or when using jackd2. It's all certainly very odd.
I'm still trying to figure out what is going on with the audio crackling. Here's what I've identified that I can do so far to avoid the crackling problem: 1) Use the linux-image-6.1.0-17-amd64 or earlier kernel package along with pipewire 2) Use the linux-image-6.1.0-18-amd64 or later kernel package with pipewire stopped and pointing audio clients at the ALSA devices natively or use jackd2 1.9.21~dfsg-3 or pulseaudio 16.1+dfsg1-2+b1 I still don't understand why the kernel versions matter but I have been able to identify that it is not a problem specifically with the Debian built kernels. I have run experiments where I build a kernel from the official 6.1 releases from kernel.org using the kernel config file from linux-image-6.1.0-17-amd64 and accepting all defaults when running make oldconfig. Doing some bisecting I've found the audio crackling does not happen with 6.1.52, which is what linux-image-6.1.0-12-amd64 is built from, and does happen with 6.1.75, which sits between linux-image-6.1.0-17-amd64 and linux-image-6.1.0-18-amd64. At this moment my machine is running 6.1.112 which I built myself and configured as mentioned earlier. The audio crackling was very bad with pipewire 1.2.4-1~bpo12+1. After 3 days of validation I have had no problems at all using 6.1.112 with pulseaudio 16.1+dfsg1-2+b1.
Hello, I installed the pipewire update in backports on Oct 15 and it certainly has made things a lot better. With the new version of pipewire and the modern kernels the frequency and severity of the audio crackling is severely reduced. In firefox I typically experience a small amount of crackling for about a second at the very start of sound in a tab. Occasionally a little bit of crackling may work it's way in. Playing Skyrim under Proton Experimental is also usually crackle free though some times the crackling can be moderate but it does not last very long. I looked at the change log for the 1.2.5 pipewire release and I did not see anything mentioned that might apply to the audio crackling aside from the generic "Some more fixes and improvements." I've started a new experiment with the Linux kernel 6.1.112 build I made using the config file from the linux-image-6.1.0-17-amd64 package. I've set the kernel preemption mode to "full" which is a move away from the default of "none" under the hypothesis that pipewire isn't getting CPU fast enough for the very small audio buffers it has in the default configuration. Using the "full" preemption mode does not seem to have had any appreciable effect if any at all. Unfortunately though while the situation is very much improved and tolerable for casual use (if still annoying) pipewire still isn't reliable enough to do something like record live audio especially if the opportunity for multiple takes didn't exist.
It looks like changing the kernel preemption mode to full made the intermittent audio crackling when playing Skyrim under Proton Experimental better. It did not eliminate or noticeably change the issue with the around 1 second of audio crackling at the start of audio streams with all applications.
I'm seeing no realtime threads from pipewire jack in Trixie. Pipewire seems to be following rlimits for nice but not passing on realtime priority. It appears to itself be gaining realtime priority for it's data loop thread. I can get realtime threads through yabridge and alsa but not pipewire jack. Logging is not helping with the source of the problem. It was entirely functional in bookworm. I've tested with rtkit enabled and disabled. With rtkit enabled, pipewire doesn't seem to request realtime access but other apps do successfully. With rtkit disabled pipewire also doesn't pass realtime priority to jack threads but I don't find logging complaining that it tried and failed. I have other applications (yabridge, bitwig/reaper through alsa) that gain realtime access without issue but I'm also seeing ardour complain that it can't get realtime IO threads and from the ardour code in git that's entirely rlimit based. If this is a bigger problem than pipewire there's some evidence for it but a lot of evidence against. I haven't found any bug reports in the pipewire bug tracker that seem related and post 1.4.2 release. I'm using the xanmod 6.15.9-x64v3 kernel but also tested with 6.12 from trixie. Neither have CONFIG_RT_GROUP_SCHED enabled so it doesn't seem to be a cgroup interaction. Both have CONFIG_PREEMPT_DYNAMIC. I don't have jackd or jackd2 installed though I did with bookworm and tested with and without (after purge) and the ld.so.conf.d file is in place as per the package. Even so I tested via pw-jack and no difference.