For my testing with generic audio HAT’s on the Pi5, I’ve added these 2 lines to my userconfig.txt /and it has made my DSD playback more consistent and reliable, to the point that I now consider it a non-issue.
dtoverlay=i2s-dac
param=i2s_mclk=on
I also now have a better understanding as to why 192/24 thru the same HAT’s i2s/hdmi is unplayable/no-sound, as it requires more overhead than just DSD. Since I can reliably play DSD thri i2s/HDMI now, I’m happy to settle switching to coax if I really need to play some 192/24. Here’s what ChapGPT told me:
Root cause of PCM192 failure (why DSD seems better)
DSD (Native) on your setup actually pushes fewer interrupts per second because the data path is almost raw serial; it doesn’t need the resampling and buffer juggling that 192 kHz PCM does.
Meanwhile:
- PeppyMeter + FusionDSP + CamillaDSP + Volumio UI all tap or copy the PCM stream → CPU spikes → ALSA buffer underruns.
- The Pi 5 kernel 6.12.x still uses 48-sample DMA chunks for
snd_rpi_hifiberry_dac; at 192 kHz, that’s ~4 kHz interrupt rate — any hiccup gives silence. - Overclocking + GPU load (Waveshare panel with KMS) magnify the latency spikes.
So you’re hitting “perfect storm” timing limits.
Ways to stabilize PCM 192 / 24 playback while keeping your full plugin stack
| Fix | How | Why |
|---|---|---|
| Increase ALSA buffer | Edit /etc/mpd.conf section audio_output {}: |
|
audio_output { … buffer_time "2000000" period_time "0" } |
Doubles I²S DMA buffer; reduces underruns. | |
| Pin MPD to one core | sudo taskset -cp 3 $(pidof mpd) (choose an unused core) |
Isolates MPD from Chrome/FusionDSP threads. |
| Set CPU governor to performance | sudo cpufreq-set -g performance |
Prevents frequency scaling jitter. |
| Relax FusionDSP latency | In FusionDSP → Settings → Processing latency: set to High (1024 samples) | Lets the chain absorb small underruns. |
| Use DoP for 192/24 “problem” albums | Temporarily upsample to DSD64; DO400 handles it natively | Offloads high-rate PCM path from ALSA. |
| Try 48 kHz kernel fragment size | Add to /boot/cmdline.txt (same line): |
|
snd_bcm2835.enable_compat=1 |
Forces 256-sample fragments (less IRQs). |
^^^I’ve tried everything listed above to no avail.
Reviewing more logs with ChatGPT, I also asked it to help me optimize anything else that may improve DSD playback, which actually got me to understand a lot more than I really wanted to about the hardware stack between the Pi and the final audio out…I’m sharing the following in hopes for my understanding and not requesting changes for my unqiue usage:
What the log actually says
failed to open /dev/dri/renderD128: Permission denied … glx: failed to create dri2/dri3 screen … failed to load driver: drm-rp1-dsi- The Pi 5 display driver (rp1-dsi) can’t initialize with the permissions the
volumiouser has. Volumio’s kiosk/UI then falls back in a broken state and keeps retrying GLX. This is noisy and can coincide with audio underruns.
- The Pi 5 display driver (rp1-dsi) can’t initialize with the permissions the
Failed to create /home/volumio/.cache/mesa_shader_cache … Permission denied- The UI process can’t write its shader cache (home dir perms). Again, churn.
No method [serialMonitorAction] in plugin inputs- Harmless; an Inputs plugin call that doesn’t exist. Ignore.
None of those lines are an ALSA/I²S error, but cleaning them up removes a source of timing noise while we verify the DSD path.
Fix the noisy display/permission issues (safe)
Run these once, then reboot:
# 1) Give volumio access to GPU nodes
sudo usermod -aG video,render volumio
# 2) Ensure udev defaults keep /dev/dri usable
echo 'SUBSYSTEM=="drm", KERNEL=="card*", GROUP="video", MODE="0660"' | sudo tee /etc/udev/rules.d/70-dri-perms.rules
echo 'KERNEL=="renderD*", GROUP="render", MODE="0660"' | sudo tee -a /etc/udev/rules.d/70-dri-perms.rules
sudo udevadm control --reload
sudo udevadm trigger
# 3) Give the UI a cache folder it can write
sudo mkdir -p /home/volumio/.cache/mesa_shader_cache_db
sudo chown -R volumio:volumio /home/volumio/.cache
New Volumio Mobile App – Beta Release