Repository navigation
[Raspberry Pi 5 / VC6 HDMI] HDMI multichannel audio speaker channels randomly rotate during playback #7750
Description
Describe the bug
I am experiencing an intermittent HDMI multichannel audio routing issue on a Raspberry Pi 5 connected to a Yamaha RX-A1080 AV receiver.
After several track changes (typically 2–10, but not consistently), the physical speaker assignments suddenly become incorrect. The issue occurs with different audio players and sources, including local playback with mpv, Parole and remote playback.
The same audio setup works correctly on an HP computer.
Hardware and software
Raspberry Pi 5
Kernel: 6.18.60+rpt-rpi-2712
HDMI output: VC4/VC6 HDMI0
AV receiver: Yamaha RX-A1080
Receiver supports multichannel LPCM, including 5.1 and 7.1.
PipeWire audio routing using a custom virtual sink named Quadra.
HDMI output configured for 5.1 or 7.1.
Actual behaviour
The speaker channel assignments suddenly rotate during playback.
For example, with a channel announcement test:
FL is heard from the rear left speaker.
FR is heard from the rear right speaker.
FC is heard from the front left speaker.
LFE is heard from the front right speaker.
Restarting any one of the following services restores the correct channel assignments:
pipewire
pipewire-pulse
wireplumber
The issue is not specific to one audio player.
Important observations
I monitored the HDMI controller registers through debugfs:
/sys/kernel/debug/dri/axi:gpu/hdmi0_regs
In 7.1 mode, I observed:
When the channels are rotated:
HDMI_MAI_CHANNEL_MAP = 0x76543210
HDMI_MAI_CTL = 0x0000b088
When the channels are correct:
HDMI_MAI_CHANNEL_MAP = 0x76543210
HDMI_MAI_CTL = 0x00003088
The channel map is identical in both states.
The difference in HDMI_MAI_CTL is 0x8000, corresponding to the DLATE status flag (MAI FIFO underrun / audio stream received too slowly).
The same pattern was previously observed in 5.1 mode:
Rotated: HDMI_MAI_CTL = 0x0000b068
Correct: HDMI_MAI_CTL = 0x00003068
So the behaviour is not limited to 5.1; it also occurs in 7.1.
The DLATE flag appears correlated with the channel rotation, although I cannot establish whether it is the cause or a consequence.
PipeWire node properties and audio links remain unchanged between the correct and incorrect states. The HDMI ELD information and ALSA hardware parameters also remain unchanged.
Expected behaviour
HDMI speaker channel assignments should remain stable during playback and across track changes, regardless of whether the output is configured for 5.1 or 7.1.
Question
Could this be related to MAI FIFO underruns, HDMI audio DMA handling, or the VC6 HDMI audio controller state?
The fact that restarting a PipeWire-related service restores the correct channel assignments may indicate that reinitialising the HDMI audio stream resets an incorrect hardware state.
Steps to reproduce the behaviour
I use this remap file that initally works fine on my speakers, and when I play stereo or a quad after several changes tack changes the physical speaker assignments suddenly become incorrect.
nico@raspberrypi:~ $ cat .config/pipewire/pipewire.conf.d/audio-remap.conf
context.modules = [
{
name = libpipewire-module-loopback
args = {
capture.props = {
media.class = "Audio/Sink"
node.name = "Quadra"
node.description = "Quadra"
audio.channels = 6
audio.position = [ FL FR RL RR FC LFE ]
audio.rate = 96000
}
playback.props = {
node.name = "playback.quadra"
audio.channels = 6
audio.position = [ FL FR FC LFE RL RR ]
target.object = "alsa_output.platform-107c701400.hdmi.hdmi-surround"
stream.dont-remix = false
audio.rate = 96000
channel.mapping = [ FL FR RL RR FC LFE ]
}
}
}
]
It works initallty just fine
Device (s)
Raspberry Pi CM5
System
nico@raspberrypi:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2026-04-21
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 4ad56cc850fa60adcc7f07dc15879bc95cc1d281, stage4
nico@raspberrypi:~ $ vcgencmd version
2025/12/08 19:29:54
Copyright (c) 2012 Broadcom
version 2226a853 (release) (embedded)
nico@raspberrypi:~ $
Logs
No response
Additional context
No response
Activity
popcornmix commentedon Nov 11, 2026
The DLATE bit does indicate the HDMI audio fifo ran empty, which can cause a channel swap, depending on how many samples were lost. The audio is supplied through DMA, and this suggests contention for SDRAM.
What else are you running when this occurs?
I notice you have
audio.rate = 96000- does it still occur with 48000?For reproduction, getting the minimal environment that reproduces the issue would be useful.
I suspect it can fail with just (multi-channel) alsa. But it will need the SDRAM contention.
Are you able to run:
and observe the DLATE bit in HDMI_MAI_CTL when running what you normally run.
I'll also see if I can reproduce with this setup, but reproduction may depend on some specific hardware or software.
Are you using one or two hdmi displays? 4kp60 or lower?
sdcard boot or usb/ssd?
Any usb devices attached? Any HATs? Anything else connected?
I assume this is a RPiOS 64-bit trixie image? With desktop?
Any software that is typically running when this occurs?
tarass60 commentedon Nov 11, 2026
Nothing, I use console control with mpv basically, but I reproduce this from several configurations.
Yes
speaker-test -D sysdefault:CARD=vc4hdmi0 -c 8 -r 96000
speaker-test 1.2.14
Le périphérique de lecture est sysdefault:CARD=vc4hdmi0
Les paramètres du flux sont 96000Hz, S16_LE, 8 canaux
Utilisation de 16 octaves de bruit rose
Erreur d'ouverture à la lecture : -16,Périphérique ou ressource occupé
device busy...
4kp60 with a display after the Yamaha receiver, or a EDID emulator or nothing, produces the same problem.
usb ssd disk.
nico@raspberrypi:~/.config/pipewire/pipewire.conf.d $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 1058:10b8 Western Digital Technologies, Inc. Elements Portable (WDBU6Y, WDBUZG)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 045e:0800 Microsoft Corp. Wireless keyboard (All-in-One-Media)
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
now but changes make no difference.
nico@raspberrypi:~/.config/pipewire/pipewire.conf.d $ aplay -l
**** Liste des périphériques matériels PLAYBACK ****
carte 0 : vc4hdmi0 [vc4-hdmi-0], périphérique 0 : MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Sous-périphériques : 0/1
Sous-périphérique #0 : subdevice #0
carte 1 : vc4hdmi1 [vc4-hdmi-1], périphérique 0 : MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Sous-périphériques : 1/1
Sous-périphérique #0 : subdevice #0
carte 2 : sndrpihifiberry [snd_rpi_hifiberry_dacplusadcpro], périphérique 0 : HiFiBerry DAC+ADC Pro HiFi multicodec-0 [HiFiBerry DAC+ADC Pro HiFi multicodec-0]
Sous-périphériques : 1/1
Sous-périphérique #0 : subdevice #0
But I had the same problem before Hifiberry hat.
nico@raspberrypi:
/.config/pipewire/pipewire.conf.d $ cat /etc/os-release/.config/pipewire/pipewire.conf.d $ echo "$XDG_CURRENT_DESKTOP"uname -m
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.7
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
aarch64
nico@raspberrypi:
nico@raspberrypi:
/.config/pipewire/pipewire.conf.d $ dpkg -l | grep -E 'raspberrypi-ui-mods|lxde|lxqt|xfce4|gnome-shell|mate-desktop|wayfire|labwc'bpo13+1 arm64 window-stacking Wayland compositorii autotouch 0.1 all Automatic touch screen association for labwc
ii labwc 0.20.2-1
ii libmate-desktop-2-17t64:arm64 1.26.2-1.2 arm64 Library with common API for various MATE modules (library)
ii libxfce4ui-2-0:arm64 4.20.1-1 arm64 widget library for Xfce - Gtk+3 variant
ii libxfce4ui-common 4.20.1-1 all common files for libxfce4ui
ii libxfce4util-bin 4.20.1-1 arm64 tools for libxfce4util
ii libxfce4util-common 4.20.1-1 all common files for libxfce4util
ii libxfce4util7:arm64 4.20.1-1 arm64 Utility functions library for Xfce4
ii mate-desktop-common 1.26.2-1.2 all Library with common API for various MATE modules (common files)
nico@raspberrypi:
/.config/pipewire/pipewire.conf.d $ cat /etc/X11/default-display-manager/.config/pipewire/pipewire.conf.d $ ls -l /usr/share/xsessions/ /usr/share/wayland-sessions/ 2>/dev/null/usr/sbin/lightdm
nico@raspberrypi:
/usr/share/wayland-sessions/:
total 8
-rw-r--r-- 1 root root 131 21 août 19:24 labwc.desktop
-rw-r--r-- 1 root root 93 6 oct. 10:58 rpd-labwc.desktop
/usr/share/xsessions/:
total 12
-rw-r--r-- 1 root root 86 21 juin 2024 lightdm-xsession.desktop
-rw-r--r-- 1 root root 198 13 mars 2025 openbox.desktop
-rw-r--r-- 1 root root 89 6 oct. 10:58 rpd-x.desktop
nico@raspberrypi:~/.config/pipewire/pipewire.conf.d $
Basically nothing I'm SSH-connected.
popcornmix commentedon Nov 11, 2026
you may need
systemctl --user stop pipewire.socket pipewire-pulse.socket pipewire pipewire-pulse wireplumberbefore running speaker-test
popcornmix commentedon Nov 11, 2026
Is a track video or just audio?
Does this mean channels don't swap in the middle of track - just following a track switch?
tarass60 commentedon Nov 11, 2026
Ok you scared my cat ! ;-)
Surveillance HDMI démarrée : 17:30:47
17:30:47 : HDMI_MAI_CHANNEL_MAP = 0x00543210
HDMI_MAI_CTL = 0x00000400
at the begining of the test :
17:30:57 : HDMI_MAI_CHANNEL_MAP = 0x76543210
HDMI_MAI_CTL = 0x00003088
at the end of the test
17:31:12 : HDMI_MAI_CHANNEL_MAP = 0x76543210
HDMI_MAI_CTL = 0x00000400
tarass60 commentedon Nov 11, 2026
the channels a correctly mapped.
tarass60 commentedon Nov 11, 2026
just audio track, I don't remember it swichtes in the middle of a track allways at the beginning, even the very first.
popcornmix commentedon Nov 11, 2026
Thanks for the register dumps - the DLATE bit was the key.
I can reproduce this without any SDRAM load: a single audio underrun is enough. The HDMI audio
FIFO was only reset when the device is opened, but after an underrun (or a pause/restart by
PipeWire) the stream is restarted without being reopened. That leaves DLATE set and shifts an
8 channel stream by 4 channels - exactly what you are hearing. Restarting PipeWire reopens the
device, which is why that fixes it.
#7751 should fix this. Once its build has finished you can test it with:
This is a test kernel - please read the rpi-update caveats
and back up anything important first. Please report whether the channels stay correct across track changes.