https://bugs.kde.org/show_bug.cgi?id=513410
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #7 from [email protected] --- I've been trying to troubleshoot this odd behavior on my own for some time now. I couldn't find exact references to the issue online, so I assumed it was some obscure issue with my system configuration, but after stumbling across this thread I feel a bit less crazy now haha. Sharing my experience here in case it's helpful for others (apologies in advance for long post, there's a lot of detail that I think is relevant). Based on my own testing, I've found 2 separate issues that cause crackling when playing audio on my system: 1. Pipewire automatically resampling audio to match the default clock rate 2. FLAC files encoded with non-zero levels of compression, when played via certain applications (incl. Elisa) ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ ISSUE #1: Some of my 44.1kHz FLAC files would produce intermittent and random/unpredictable crackling when played through Elisa. I could play the same file multiple times, and sometimes no crackling would occur at all, but other times it would occur during different parts of the track. This issue went away when I configured Pipewire to passthrough audio directly to the output device whenever possible, avoiding resampling, via the following setting: In ~/.config/pipewire/pipewire.conf.d/allowed-rates.conf (can use a different filename): context.properties = { default.clock.allowed-rates = [ 44100 48000 88200 96000 192000 ] } [Source: https://wiki.archlinux.org/title/PipeWire#Changing_the_allowed_sample_rate(s)] By default, Pipewire forcibly resamples everything to 48kHz. And although the built-in SPA resampler is generally high-quality, it seems to occasionally introduce crackling for some reason. (Maybe it gets overloaded? I have no idea; this is the only explanation I can think of as to why skipping resampling would fix the issue.) Note that the passthrough only works when the source file sample rate is supported natively by the output device. After restarting pipewire & pipewire-pulse, play non-default-rate audio and confirm that the input and output rates match using pw-top. To be clear, this doesn't seem to be an Elisa issue, and is a good thing to check first for anyone experiencing similar problems. > I'm using PipeWire 1.6.4 configured with a 48 kHz clock rate The "Snippet of Cello Concerto No. 1 in A Minor, Op. 33 (Arr. for Chamber Orchestra by Ilan Rechtman).flac" file that you linked is 96kHz, so this may be the solution. On my end there's no crackling at all when I use the above configuration. ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ ISSUE #2: Despite fixing the inconsistent audio crackling, I still had some FLAC files which produced 100% consistent crackling no matter what throughout the track. After much testing, I discovered that re-encoding with level 0 FLAC compression was the solution. I confirmed this using the orignal file attached to this report, "01 - Christian Lindberg - Ding Dong Merrily on High I.flac" It produces crackling every single time it's played through Elisa. Then I ran the following command: sox "01 - Christian Lindberg - Ding Dong Merrily on High I.flac" -C 0 "uncompressed.flac" Per the SoX documentation, this will re-encode the file (losslessly) with no/minimal compression: > SoX can write native FLAC files according to a given or default compression > level. 8 is the default compression level and gives the best (but slowest) > compression; 0 gives the least (but fastest) compression. The compression > level is selected using the -C option (see sox_ng(1)) with a whole number > from 0 to 8. [Source: https://man.archlinux.org/man/soxformat_ng.7.en#FORMATS_&_DEVICE_DRIVERS (under ".flac")] You can also use FFMPEG instead if you prefer: ffmpeg -i "<input>.flac" -c:a flac -compression_level 0 -c:v copy "<output>.flac" Playing the resulting "uncompressed.flac" output file in Elisa yields no crackling whatsoever on my system, no matter how many times I listen to it. I'm curious if this also works for others. To further test this potential solution, I converted all of my crackling files to non-compressed FLAC and have been listening via Elisa for a while now, without any noticeable reoccurrence of the issue thus far. This may imply it's related to how fast the compressed audio data can be decoded, although that's purely speculative on my part. Though I'm a bit skeptical of that explanation since I have a fairly new AMD APU that should be able to handle that no problem, and I can play the exact same compressed FLAC file via Firefox with no crackling at all (interestingly VLC also crackles on playback). I thought this may have something to do with Pipewire's quantum settings, which limit the amount of time that audio can be processed/decoded by the system before being sent to the output device. If that takes too much time, it results in an "Xrun" (aka. the audio cuts out entirely for the duration of the quantum period). However, when listening to the crackling file in Elisa and monitoring for Xruns via pw-top, there were 0 errors/Xruns reported for the entire duration, suggesting that the issue may be elsewhere. Since I'm not super knowledgable about the deep technical side of Linux audio, this was as far as I've gotten thus far. IMO there's no reason why simple FLAC compression should cause such noticeable crackling on anything but really low-end CPUs. Maybe there's some bottleneck in Elisa, or maybe it's something deeper in the audio stack? I'm really not sure. ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ SYSTEM CONFIGURATION: Distribution: Arch Linux Elisa Version: 26.04.0-1 (https://archlinux.org/packages/extra/x86_64/elisa/) Processors: 16 x AMD Ryzen 7 7840U w/ Radeon 780M Graphics Memory: 32 GiB of RAM KDE Plasma Version: 6.6.4 KDE Frameworks Version: 6.25.0 Qt Version: 6.11.0 Kernel Version: 6.19.10-hardened1-1-hardened (64-bit) Graphics Platform: Wayland pipewire / pipewire-pulse / pipewire-alsa / pipewire-jack / pipewire-audio Version: 1.6.4-1 wireplumber Version: 0.5.14-1 Relevant Pipewire Config (all default aside from allowed-rates): "default.clock.allowed-rates": "[ 44100 48000 88200 96000 192000 ]", "default.clock.max-quantum": 2048, "default.clock.min-quantum": 32, "default.clock.quantum": 1024, "default.clock.quantum-floor": 4, "default.clock.quantum-limit": 8192, "default.clock.rate": 48000 Please lmk if you want any more info/testing and I'll be happy to oblige! -- You are receiving this mail because: You are watching all bug changes.
