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

Aberta
  • Algo errado?
#7,603 11 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
52/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
c, linux, raspberry-pi
Domínio
audio-video-rtc, embedded-iot, operating-systems

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
C
Estrelas
13.3k
Forks
5.5k
Merge médio
3d 20h
PRs com merge (30d)
27

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de raspberrypi/linux

Todas as issues de raspberrypi/linux

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.