designware_i2s BCM2712: trigger(STOP) permanently breaks DMA restart — WRITEI_FRAMES returns 0 until module reload (RPi5)

[yayster]

Describe the bug

Platform

• SBC: Raspberry Pi 5 (BCM2712, arm64)
• Kernel: 6.12.75+rpt-rpi-2712 (uname -r: 6.12.75+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2025-03-31) aarch64)
• HAT: Fusion HAT+ — Google Voice HAT I2S codec (sndrpigooglevoi, ALSA card 2)
• Amp: MAX98357A (I2S Class D, built into HAT)
• Amp enable: sysfs GPIO — /sys/class/fusion_hat/fusion_hat/speaker

Bug Description

On Raspberry Pi 5 (BCM2712), the designware_i2s driver has a broken trigger(START) path after any trigger(STOP). Once any ALSA PCM client exits (ALSA always calls trigger(STOP) on close), the DMA engine permanently stops restarting. Every subsequent SNDRV_PCM_IOCTL_WRITEI_FRAMES ioctl returns 0 frames written in blocking mode — the kernel accepts the call with no error, but no frames are clocked out on the I2S bus. The only recovery is a full module reload.

Steps to reproduce the behaviour

Steps to Reproduce

# Play first file — works fine
aplay -D hw:sndrpigooglevoi,0 -f S32_LE -r 48000 -c 2 /tmp/test.wav
# aplay exits → kernel calls trigger(STOP)

sleep 10

# Play second file — silent, rc=0
aplay -D hw:sndrpigooglevoi,0 -f S32_LE -r 48000 -c 2 /tmp/test.wav

Symptoms

• aplay exits with rc=0
• SNDRV_PCM_IOCTL_WRITEI_FRAMES returns 0 (blocking mode) on every write — kernel acknowledges writes but DMA produces no output
• SNDRV_PCM_IOCTL_DRAIN and DROP succeed
• /proc/asound/card2/pcm0p/sub0/status: hw_ptr and appl_ptr do not advance
• No ALSA errors, no kernel errors in dmesg
• Physical speaker pop on GPIO toggle confirms amp is alive
• Issue is not PipeWire suspend (session.suspend-timeout-seconds = 0 confirmed, also reproduces with PipeWire masked)

strace (failing playback)

# Every write during the silent (broken) playback:
ioctl(4, SNDRV_PCM_IOCTL_WRITEI_FRAMES, {frames=1024, ...}) = 0   # 0 frames written each time
ioctl(4, SNDRV_PCM_IOCTL_WRITEI_FRAMES, {frames=1024, ...}) = 0
# ... repeated for full file duration
ioctl(4, SNDRV_PCM_IOCTL_DRAIN, 0) = 0
ioctl(4, SNDRV_PCM_IOCTL_DROP, 0) = 0

Root Cause Analysis

The designware_i2s DMA path on BCM2712 fails to re-initialize after trigger(STOP). The specific sequence:

1. First aplay opens device → trigger(START) → DMA starts, audio works
2. aplay exits → ALSA calls trigger(STOP) → DMA halts
3. Next aplay opens device → trigger(START) is called but DMA never restarts
4. WRITEI_FRAMES ioctls return 0 indefinitely (kernel-side ring buffer pointers do not advance)

This is not a clock-gating or amp wakeup issue — we exhausted those hypotheses (sox silence padding, GPIO timing, PipeWire disable, dmix keepalive). The DMA engine itself does not restart after trigger(STOP).

Workaround

Use a single persistent aplay process for the lifetime of the system — never let it call trigger(STOP). Feed silence between audio bursts via a pipe:

# One aplay, never exits
proc = subprocess.Popen(
    ["aplay", "-D", "hw:sndrpigooglevoi,0", "-f", "S32_LE", "-r", "48000", "-c", "2", "-"],
    stdin=subprocess.PIPE
)
# Silence writer thread keeps DMA fed between utterances
# Speech PCM is injected into proc.stdin on demand

Additionally, a boot-time oneshot service reloads the module to ensure a clean DMA state:

# /etc/systemd/system/i2s-module-reset.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c "modprobe -r snd_soc_dwc_i2s; modprobe snd_soc_dwc_i2s"

Device (s)

Raspberry Pi 5

System

Platform

• SBC: Raspberry Pi 5 (BCM2712, arm64)
• Kernel: 6.12.75+rpt-rpi-2712 (uname -r: 6.12.75+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2025-03-31) aarch64)
• HAT: Fusion HAT+ — Google Voice HAT I2S codec (sndrpigooglevoi, ALSA card 2)
• Amp: MAX98357A (I2S Class D, built into HAT)
• Amp enable: sysfs GPIO — /sys/class/fusion_hat/fusion_hat/speaker

Logs

No response

Additional context

Impact

Any application on RPi5 with a sndrpigooglevoi (Google Voice HAT) or other designware_i2s-backed I2S device that opens and closes the PCM device more than once will hit this silently. The symptoms (rc=0, no errors, data written but no audio) make this very hard to diagnose. Other RPi5 users with I2S HATs are likely affected.

Kernel Version

Linux picar 6.12.75+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2025-03-31) aarch64 GNU/Linux