linux icon indicating copy to clipboard operation
linux copied to clipboard
verified publisher icon raspberrypi

Audio drops after seeing in VLC. Also similarly in Audacity and Chromium.

Open programme957 opened this issue 2 months ago • 3 comments

Describe the bug

Audio stops even though VLC player continues to play. Usually a restart of the program restores audio, sometimes a reboot is needed. Have tried to diagnose with Claude, adjusting buffer settings etc. Switched to ALSA output on VLC.

Steps to reproduce the behaviour

Open m4u file in VLC click to middle of file and use left/right arrows to seek until audio stops. VLC will continue playing but there is no audio. Speakertest usually worksat this point, not always.

Device (s)

Raspberry Pi 5

System

Raspberry Pi reference 2025-05-13 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 5dabc7dc940059dfbc46af5d97b60a1e812523dd, stage4

2025/10/17 10:48:37 Copyright (c) 2012 Broadcom version b66568da (release) (embedded)

Linux raspberrypi 6.12.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16) aarch64 GNU/Linux

Summary from Claude -

Bug Report: Pi 5 HDMI Audio Fails When Seeking in Media Players

System Information:

  • Hardware: Raspberry Pi 5
  • OS: Debian GNU/Linux 12 (bookworm)
  • Kernel: 6.12.47+rpt-rpi-v8
  • Audio System: PipeWire
  • HDMI Port: Port 0 (platform-107c701400.hdmi)
  • Output: HDMI to monitor with built-in speakers

Problem Description: HDMI audio completely stops working when seeking/jumping in media players (VLC, Audacity, Chromium). The audio system enters a stuck state that cannot recover without killing processes.

Symptoms:

  1. Audio works normally during continuous playback
  2. Seeking/jumping in timeline causes audio to stop completely
  3. Video continues playing but no audio output
  4. pactl list sinks short shows sink as RUNNING
  5. amixer shows audio unmuted [on]
  6. speaker-test through PipeWire fails (no sound)
  7. Direct hardware test speaker-test -D hw:0,0 returns "Device or resource busy"
  8. Application restart alone does not fix the issue
  9. Requires sudo fuser -k /dev/snd/* and systemctl --user restart pipewire wireplumber to recover
  10. Sometimes even killing processes doesn't restore audio without full reboot

Reproduction Steps:

  1. Play any video/audio file in VLC
  2. Seek/jump to a different position in the timeline
  3. Audio stops completely
  4. PipeWire shows RUNNING and unmuted, but produces no sound

What We've Tried (No Effect):

PipeWire Configuration Changes:

  • Increased buffer sizes (quantum 2048, 4096)
  • Increased min/max quantum limits
  • Added link.max-buffers = 64
  • Modified stream latency settings
  • Changed resample quality

System Configuration:

  • Added to /boot/firmware/config.txt: 
    hdmi_force_hotplug=1
hdmi_drive=2
hdmi_force_edid_audio=1
  • Switched between HDMI port 0 and port 1
  • Tried both PipeWire and direct ALSA output in VLC
  • Full system update (apt full-upgrade)

Runtime Fixes Attempted:

  • Restarting PipeWire/WirePlumber
  • Restarting applications
  • Unmuting audio (was not muted)
  • Direct hardware access tests

Key Findings:

  • Problem occurs with both PipeWire AND direct ALSA output - rules out PipeWire as root cause
  • speaker-test directly to hardware (-D hw:0,0) shows device locked/"busy" when audio fails
  • Kernel logs show no errors during audio failure
  • journalctl shows historical xrun/broken pipe errors: spa.alsa: hdmi:1p: snd_pcm_mmap_commit error: Broken pipe
  • Issue is specific to buffer discontinuities (seeking) - continuous playback works fine

Conclusion: This appears to be a driver-level bug in the Pi 5's vc4-hdmi audio driver where seeking operations cause the ALSA device to deadlock/hang, requiring process termination to recover. The driver cannot handle stream discontinuities properly.

Potential Workaround (Untested): USB audio device may bypass the HDMI driver issue.

Logs

No response

Additional context

No response

programme957 avatar Nov 01 '25 21:11 programme957

Can you confirm if the issue occurs with a fresh trixie image?

Bookworm is unlikely to get much in the way of bug fixes now (security fixes only).

popcornmix avatar Nov 02 '25 16:11 popcornmix

My symptoms are that i have small drops in audio and some dmesg messages very similar to the bug report on debian kernel mailing list. I'm running on trixie. My setup is as a source alsa_input.usb-HiFimeDIY_Audio_UR23_USB_SPDIF_Rx-01.iec958-stereo and sink is alsa_output.usb-Schiit_Audio_Schiit_Modi_3-00.analog-stereo. This is happening on 3B. I too throwed everything and the kitchen sink at it. The glitching was especially bad if a docker with traefik and homebridge running at the same time. Turning off docker made the random audio drops happen much less seldom, but they do occur maybe every 10-20 minutes and then suddenly after using audio for an hour or more all audio is gone and only a full reboot fixes the issue.

https://pastebin.com/BRGKCB38

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108496

fheinonen avatar Nov 02 '25 17:11 fheinonen

@fheinonen your issue doesn't sound related to this issue. Please create your own issue.

popcornmix avatar Nov 02 '25 17:11 popcornmix