HDMI audio fails on Pi 5 with "-22" channel mapping error when connected - TV reports FL/FR bit unset in Speaker Allocation Data Block

Start with the hdmi-audio-codec and vc4_hdmi channel-mapping code, then reproduce using an EDID whose Speaker Allocation Data Block has FL/FR unset and extended speaker bits set. Check the dmesg errors and confirm that PCM preparation no longer fails with -22 and HDMI audio initializes instead of exposing only a Dummy Output.

Describe the bug

I recently bought a Pi 5 and installed RECALBOX using the Pi Manager. Result: HDMI audio completely fails to initialize on a Raspberry Pi 5 (Recalbox distribution) when connected to a Philips OLED809 TV (directly, no intermediate HDMI devices). Video works perfectly, audio never initializes, and only a "Dummy Output" sink is available. A SONOS Arc Ultra is connected to my TV via eARC.

Since I'm not an expert, I looked into the issue with the help of AI, with the following result.

Display: Philips OLED809 (77OLED809), connected directly via HDMI (issue reproduces both directly and through an intermediate HDMI-audio-passthrough device, ruling out the intermediate device as the cause)

dmesg output (repeats hundreds of times within ~150ms of each boot, always at ~3.5s uptime)

hdmi-audio-codec hdmi-audio-codec.1.auto: Not able to map channels to speakers (-22)
hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22

Root cause analysis

I extracted and decoded the TV's EDID (cat /sys/class/drm/*/edid, decoded with edid-decode). The CTA-861 Speaker Allocation Data Block payload is 7E 03 57.

Decoding byte 1 (0x7E = 01111110):

• bit0 (FL/FR — Front Left/Right): 0 (NOT SET)
• bit1 (LFE): 1
• bit2 (FC): 1
• bit3 (RL/RR): 1
• bit4 (RC): 1
• bit5 (FLC/FRC): 1
• bit6 (RLC/RRC): 1
• bit7 (FLW/FRW): 0

The TV declares support for LFE, Center, Rear, Front-of-Center, and various Top/Bottom extended speaker positions, but explicitly does not set the baseline FL/FR bit — which is unusual (virtually all real-world displays set this bit as the baseline). edid-decode -c otherwise validates this EDID without audio-related warnings (only an unrelated video-timing-range warning).

I built a modified copy of the EDID with the Speaker Allocation Data Block simplified to a standard 5.1 layout (0F 00 00: FL/FR, LFE, FC, RL/RR set; checksum recalculated) to test whether the vc4-hdmi / hdmi-audio-codec channel-mapping code trips specifically over the missing FL/FR bit combined with the extended-position bits. I was unable to get this test EDID loaded via drm.edid_firmware= on this particular distribution (read-only rootfs prevents placing the file under /lib/firmware/edid/), so I could not confirm the fix in practice — but the anomaly is a strong candidate root cause given the driver's exact failure mode ("not able to map channels to speakers").

Expected behavior

The hdmi-audio-codec / vc4_hdmi channel-mapping code should handle an EDID Speaker Allocation Data Block that has non-baseline bits set without a baseline FL/FR bit gracefully (e.g. fall back to basic stereo) rather than failing PCM prepare with -22 and leaving only a dummy audio sink.

Already ruled out

• Not related to an intermediate HDMI device (Philips Hue Play Sync Box) — reproduces with the Pi 5 connected directly to the TV.
• Not a power-supply / undervoltage issue.
• Not affected by hdmi_force_hotplug, hdmi_drive, hdmi_force_edid_audio (legacy VideoCore firmware parameters — expected to have no effect under the KMS vc4-kms-v3d driver used on Pi 5, confirmed).
• Not affected by vc4.force_hotplug=1 kernel parameter.
• Not affected by increased boot_delay (3s → 10s) — the failure is immediate and deterministic (repeats hundreds of times within ~150ms), not a hotplug-timing race.

I hope this information helps and sorry, if it makes no sense in any parts.

Steps to reproduce the behaviour

1. Connect a Raspberry Pi 5 via HDMI to a display whose EDID Speaker Allocation Data Block has bit0 (FL/FR) unset while other bits (LFE/FC/RL-RR/etc.) are set.
2. Boot and check dmesg | grep -i audio.
3. Only a "Dummy Output" PulseAudio sink is available; no working HDMI audio output.

Device (s)

Raspberry Pi 5

System

Linux RECALBOX 6.12.25-v8-16k #1 SMP PREEMPT Mon Jun 29 14:53:23 CEST 2026 aarch64 GNU/Linux

Logs

No response

Additional context

No response