Audio stuttering and crackling when transferring data through pipe on Raspberry Pi OS Bookworm #6864
Comments
|
Are you using HDMI audio or the headphone jack? The two involve processing at different levels (ALSA for HDMI and the firmware for the headphone jack). |
|
I'm using USB DAC |
|
Synchronous or asynchronous? With what kind of quality settings? |
|
|
I don't know what kind of latency tolerance that give you, but obviously not enough. Also, 32-bit samples are a bit excessive, but less so than 24-bit stereo at 384kHz. If you aren't actively using the initramfs (e.g. to load an exotic network interface driver before using an NFS rootfs), you might want to try one of the new -rt (realtime) kernel builds (althought apart from booting it and seeing that normal things seem to work, I have no real experience of it). To install the RT kernel: Note that you will need to specify the branch name ( You can switch to the new kernel using "kernel=kernel8_rt.img". And, if something goes horribly wrong, you should be able to revert to the previous kernel by commenting out or deleting that line. |
|
I'm testing with:
It's working fine for me. With your mpg123 stream I get ~1000MB/s through the pipe. Switching to a YouTube music stream (1080p HD video stream, but an animated static image rather than a full music video), and that drops down to 500MB/s. Not a single stutter. Running both streams together and mixing the audio it drops to 400MB/s, still with flawless audio (although I wouldn't recommend the Sleep Token vs. Celine Dion combo). |
|
And that's with the default 64-bit kernel. Same with WiFi instead of Ethernet. |
|
Final comment - Sleep Token's Emergence vs Spandau Ballet's True works surprisingly well. |
|
Yes. Mine says: |
|
Yes, the USB DAC is connected to a USB 2.0 port via a USB 2.0 hub, along with a keyboard and mouse. Additionally, I am using 1.5 GB of zram swap ( WiFi and Bluetooth interfaces are disabled. Ethernet adapter is RPI4 onboard, configured with NetworkManager to use static IP. The sound stuttering is not consistently reproducible. Sometimes audio playback remains smooth, while other times it begins to stutter. The only apparent variable is the timing of when the pipe streaming process is started. For example when I run the pipe streaming process and it trigger strong audio stuttering, and then simply stopping it with Ctrl+C and restarting the same command, it may result in normal audio playback without any issues. I have also occasionally noticed brief audio dropouts when loading web pages in the Firefox browser, but it happens rarely. I suspect the issue might be related to CPU core assignment - specifically, which core is handling audio playback and which core the pipe streaming process is scheduled on at the time of execution. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
Audio playback is intermittently interrupted by stuttering and crackling noises when a data stream is transferred through a pipe using standard Linux utilities. The issue is especially noticeable when performing data-heavy operations such as piping
/dev/zerothroughpvto/dev/null, and appears to be related to resource contention or scheduling.Additional Information:
Steps to reproduce the behaviour
Expected Behavior:
Audio should continue playing smoothly without interruptions, regardless of background data transfers or other light system activity.
Actual Behavior:
Note: The issue does not always manifest immediately and may require restarting the
cat /dev/zero | pv -r > /dev/nullcommand multiple times under different conditions. I have not identified a clear pattern or trigger, but once the audio disruption begins, it tends to persist consistently until the commandcat /dev/zero | pv -r > /dev/nullis restarted. Interestingly, restarting the same command - under seemingly identical system conditions (no change in background processes or overall system load), can result in normal, uninterrupted audio playback.I also observed that when the audio stuttering and crackling occurs, the
cat /dev/zero | pv -r > /dev/nullcommand reports significantly reduced throughput. Under normal conditions, it shows a data rate of around 1.1 - 1.2 GiB/s, but during audio issues, the reported speed drops to 600-700 MiB/s with noticeable and very unstable fluctuations.What’s particularly puzzling is that the issue may or may not occur under seemingly identical conditions. It appears to depend on some non-deterministic factors at the moment the command is executed.
Device (s)
Raspberry Pi 4 Mod. B
System
Raspberry Pi reference 2023-09-22
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 40f37458ae7cadea1aec913ae10b5e7008ebce0a, stage4
vcgencmd version
Apr 30 2025 13:33:39
Copyright (c) 2012 Broadcom
version 5560078dcc8591a00f57b9068d13e5544aeef3aa (clean) (release) (start)
uname -a
Linux zx80 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux
Logs
No relevant error messages appear in the dmesg log when the issue occurs.
Additional context
Similar audio interruptions and crackling can also be observed when opening moderately large schematic files in KiCad.
The text was updated successfully, but these errors were encountered: