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

[seyfarthklaus-jpg]

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

[popcornmix]

Can you post raw edid: base64 /sys/devices/platform/axi/axi:gpu/drm/card?/card?-HDMI-A-1/edid

[seyfarthklaus-jpg]

base64 /sys/devices/platform/axi/axi:gpu/drm/card?/card?-HDMI-A-1/edid

results in the following output:

/recalbox/share/system$ base64 /sys/devices/platform/axi/axi:gpu/drm/card?/card?-HDMI-A-1/edid
AP///////wBBDIstAQEBAQEiAQOAkFF4CpIQrVJErCUMUFQgAADRwIHAAQEBAQEBAQEBAQEBCOgA
MPJwWoCwWIoAoCpTAAAeAAAAEAAAAAAAAAAAAAAAAAAAAAAA/ABQaGlsaXBzIFVIRFRWAAAA/QAw
eA9GPAAKICAgICAgAdUCA3PwVnZhYF9eXT8QHyIhIAUEFBMSAxECFgE1CR8HPQfAX34HX34BFQdQ
VwcDZ34Dg34DV20DDAAUADhEIAhgAQIDaNhdxAF4gFMA4gDJ4g8H4wXAAOMGDQHrAUbQAE0Kdohe
bpblAYuEkAHmEUbQAHAAAAAAAAAAAAAAAAAAMg==

[seyfarthklaus-jpg]

Additional context:
The Speaker Allocation Data Block (CTA-861 tag 4) is 7E 03 57. Decoding byte 1 (0x7E = 01111110): bit0 (FL/FR) is not set, while LFE, FC, RL/RR, RC, FLC/FRC, and RLC/RRC bits are all set. This seems unusual. Virtually all EDIDs set the baseline FL/FR bit. I suspect this may be tripping the hdmi-audio-codec channel-mapping code (Not able to map channels to speakers (-22) at snd_soc_pcm_dai_prepare).

[seyfarthklaus-jpg]

Sorry...
The last output i posted was with the Pi connected to the Hue Sync Box and not directly to the TV. Connection over the sync Box is what i am aiming for.
The Speaker Allocation Data Block (7E 03 57) seems byte-identical in both ways, confirming the anomaly originates at the TV itself and isn't introduced or altered by the intermediate device.

[popcornmix]

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

Does the list of speakers reported in edid make any sense to you? Do you have some sort of atmos style setup with multiple satellite speakers and no traditional FL/FR?

Or do you just want stereo audio out of your speakers?

Note: I agree that the alsa driver is being unhelpful in refusing to output stereo, and that can be improved, but I'm trying to understand if you have a valid edid describing an unusual speaker setup, or if it is somehow broken/corrupt and the goal is to just get the driver to say "that speaker allocation block makes no sense - I'll just output FL/FR anyway".

[seyfarthklaus-jpg]

Good question, and I hope it clarifies things: no, this doesn't correspond to any
deliberate speaker configuration on my end.

From what i understand (more or less):
The Speaker Allocation Data Block in question seems to come from the TV's HDMI input EDID
(the port the Pi is connected to), not from anything related to my actual playback
speakers. My audio setup is a Sonos system (Arc Ultra soundbar, Sub, 2x Era 300 as
rears, plus 2x Play:5 added as additional fronts via the Sonos "Sonosequencer" app),
connected to the TV via HDMI eARC on the output side. The TV has no way of knowing
about that configuration when describing its HDMI input capabilities. The input EDID
is a fixed property of the TV itself, unrelated to what's plugged into its ARC output.

So I don't believe this is a deliberate "unusual but valid" Atmos/object-based speaker
declaration. It looks much more like a static/default value baked into the TV's HDMI
input EDID, quite possibly a Philips firmware quirk/bug, since omitting the baseline
FL/FR bit while declaring LFE/FC/rear/top positions doesn't correspond to any real
speaker layout I'm aware of.

All I actually want in the end is normal stereo (or basic 5.1 PCM/passthrough) audio out of the
Pi via HDMI. I'd fully support the driver falling back to FL/FR when
it encounters a Speaker Allocation Data Block that doesn't include the baseline
channels, rather than trying to strictly honor an inconsistent block.

I hope this helps.

[popcornmix]

#7604 is a potential workaround for your issue.
Normally I'd suggests you test it with rpi-udpate pulls/7604 (once CI build is complete), but I suspect the mechanism for Recalbox will be different.

Are you able to rebuild the kernel yourself with that PR?

[seyfarthklaus-jpg]

Thank you vermy much for this fast response!

I'm running Recalbox, which uses a read-only Buildroot environment without rpi-update or on-device build tools, so I unfortunately can't rebuild the Recalbox kernel image myself.

However, I can flash a spare SD card with standard Raspberry Pi OS (64-bit) and run sudo rpi-update pulls/7604 to test the fix directly on my Pi 5 / Philips OLED809 setup.

I'll test it on Raspberry Pi OS as soon as the CI build finishes and report back if #7604 resolves the ASoC -22 channel-mapping issue!

[seyfarthklaus-jpg]

I tested PR #7604 on Raspberry Pi OS (Kernel 6.18.48-v8-16k+) connected to the Hue Sync-Box, which is connected to the Philips OLED809.

Results:
dmesg no longer reports any Not able to map channels to speakers (-22) or ASoC errors.
speaker-test -c 2 -t wav runs smoothly and outputs stereo audio without hwparams errors.
The stereo fallback mechanism works as intended and fixes the audio initialization issue with non-standard EDIDs missing the FL/FR speaker allocation bits.

What i did in detail:

install the update:

echo '<password>' | sudo -S sh -c "SKIP_WARNING=1 rpi-update pulls/7604"

reboot

echo '<password>' | sudo -S reboot

check if update is installed:

uname -r

result:

6.18.48-v8-16k+

test speaker:

speaker-test -c 2 -t wav

result:

Playback device is default
Stream parameters are 48000Hz, S16_LE, 2 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 4 to 65536
Period size range from 2 to 32768
Periods = 4
was set period_size = 12000
was set buffer_size = 48000
 0 - Front Left
 1 - Front Right
Time per period = 2.457458
 0 - Front Left
 1 - Front Right

So i think this looks pretty good. Thank you very much for the quick fix! I hope this will find it's way to RECALBOX soon.