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

オープン
  • 何か問題がありますか？
#7,603 コメント 11 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, linux, raspberry-pi
領域
audio-video-rtc, embedded-iot, operating-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
C
スター
13.3k
フォーク
5.5k
平均マージ
3日 20時間
マージ済み PR（30日）
27

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

raspberrypi/linux のほかの issue

raspberrypi/linux の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。