HDMI audio #44

New issue

Closed

opened 2026-08-28 09:27:58 +00:00 by tiagoagueda · 2 comments

tiagoagueda commented

2026-08-28 09:27:58 +00:00

Owner

Now plausible, where before it was blocked twice over.

The HDMI controller reports an I2S input: CONFIG0_ID = 0xbf, and HDMI_CONFIG0_I2S = 0x10 is
set. Its DMA DRQ ports match the A31's — HDMI_DDC 13, HDMI_AUDIO 14 — and DMA now works
(43-audio-and-dma.md), which was the thing that made all audio impossible
before.

dw-hdmi has the audio pieces (dw-hdmi-i2s-audio, dw-hdmi-ahb-audio); which applies here
needs checking against what this instance exposes.

⚠️ Depends on #22. There is no picture yet, and it would be odd to chase HDMI audio before
the video path carries a frame. Recorded so the scope is known, not because it is next.

See 44-hdmi.md.

Now plausible, where before it was blocked twice over. The HDMI controller reports an I2S input: `CONFIG0_ID = 0xbf`, and `HDMI_CONFIG0_I2S = 0x10` is set. Its DMA DRQ ports match the A31's — `HDMI_DDC 13`, `HDMI_AUDIO 14` — and **DMA now works** ([43-audio-and-dma.md](43-audio-and-dma.md)), which was the thing that made all audio impossible before. `dw-hdmi` has the audio pieces (`dw-hdmi-i2s-audio`, `dw-hdmi-ahb-audio`); which applies here needs checking against what this instance exposes. ⚠️ **Depends on #22.** There is no picture yet, and it would be odd to chase HDMI audio before the video path carries a frame. Recorded so the scope is known, not because it is next. See [44-hdmi.md](44-hdmi.md).

tiagoagueda added the

hardware

kernel

P3-normal

labels

2026-08-28 09:27:58 +00:00

tiagoagueda commented

2026-08-28 14:22:13 +00:00

Author

Owner

Raised from P4 to P3: HDMI now produces a picture (#22), so the audio path is testable rather than theoretical. CONFIG0_ID bit 4 says the controller has an I2S input and the DMA DRQ ports match the A31's, and DMA works.

Raised from P4 to P3: HDMI now produces a picture (#22), so the audio path is testable rather than theoretical. `CONFIG0_ID` bit 4 says the controller has an I2S input and the DMA DRQ ports match the A31's, and DMA works.

tiagoagueda commented

2026-08-28 16:37:48 +00:00

Author

Owner

Working and audible, 2026-08-28 - confirmed by ear on the soundbar at 48 kHz.
Closing; the one remaining limitation is #52.

Correction to this issue's body

Its DMA DRQ ports match the A31's - HDMI_DDC 13, HDMI_AUDIO 14

Neither exists on sun9i. Both sit inside #ifndef CONFIG_ARCH_SUN9I in the BSP's
include/linux/dma/sunxi-dma.h, guarded to sun8iw1 only.

What it actually needed

CONFIG3_ID reads 0x00 - no AHB audio DMA and no GP audio - so the transmitter has an I2S
input and nothing else, and something has to feed it. That something is DAUDIO1 at
0x06002400 on DRQ 4, which is what the vendor's sunxi-hdmiaudio.c drives on sun9i. It
writes no routing register anywhere, so the link is internal and fixed.

Register file is the A83T's, but sun9i is the one SoC with no DRQSRC_DAUDIO_1_RX, so
sun4i-i2s needed a variant with the capture stream dropped.

Two faults stood between "the card plays" and "you can hear it"

Both read back as perfectly configured hardware:

pll-audio's M divider was modelled with a zero offset when the hardware divides by
M + 1, so every audio clock on the SoC ran 1.04x slow - S/PDIF included - while
clk_summary reported the exact rate that was asked for. Fixed.
dw_hdmi_i2s_hw_params() hardcodes HDMI_AUD_INPUTCLKFS_64FS and ignores mclk-fs,
while sun4i-i2s takes the slot width from the sample format - so S16_LE produced a
32 fs bit clock, half what the transmitter counts, and 16-bit playback was silent while
24-bit worked. Fixed by pinning dai-tdm-slot-width = <32> in the DT.

The transmitter's own automatic CTS counter found both, and was dismissed as
"does not add up" for several hours before being believed. It reads 148500 now, the textbook
value for 1080p60 at 48 kHz.

Still open

#52 - the 44.1 kHz clock family is 9.5% slow and silent. A 44.1 kHz track has to be
resampled to 48 kHz to play. Multichannel and non-PCM passthrough are untested; the sink
advertises 8-channel LPCM and only stereo has been used.

See 47-hdmi-audio-cec.md.

**Working and audible, 2026-08-28** - confirmed by ear on the soundbar at 48 kHz. Closing; the one remaining limitation is #52. ### Correction to this issue's body > Its DMA DRQ ports match the A31's - `HDMI_DDC 13`, `HDMI_AUDIO 14` **Neither exists on sun9i.** Both sit inside `#ifndef CONFIG_ARCH_SUN9I` in the BSP's `include/linux/dma/sunxi-dma.h`, guarded to sun8iw1 only. ### What it actually needed `CONFIG3_ID` reads `0x00` - no AHB audio DMA and no GP audio - so the transmitter has an I2S input and nothing else, and something has to feed it. That something is **DAUDIO1 at 0x06002400 on DRQ 4**, which is what the vendor's `sunxi-hdmiaudio.c` drives on sun9i. It writes no routing register anywhere, so the link is internal and fixed. Register file is the A83T's, but sun9i is the one SoC with no `DRQSRC_DAUDIO_1_RX`, so `sun4i-i2s` needed a variant with the capture stream dropped. ### Two faults stood between "the card plays" and "you can hear it" Both read back as perfectly configured hardware: 1. **`pll-audio`'s M divider was modelled with a zero offset** when the hardware divides by M + 1, so *every* audio clock on the SoC ran 1.04x slow - S/PDIF included - while `clk_summary` reported the exact rate that was asked for. Fixed. 2. **`dw_hdmi_i2s_hw_params()` hardcodes `HDMI_AUD_INPUTCLKFS_64FS`** and ignores `mclk-fs`, while `sun4i-i2s` takes the slot width from the sample format - so S16_LE produced a 32 fs bit clock, half what the transmitter counts, and 16-bit playback was silent while 24-bit worked. Fixed by pinning `dai-tdm-slot-width = <32>` in the DT. The transmitter's own automatic CTS counter found both, and was dismissed as "does not add up" for several hours before being believed. It reads 148500 now, the textbook value for 1080p60 at 48 kHz. ### Still open **#52** - the 44.1 kHz clock family is 9.5% slow and silent. A 44.1 kHz track has to be resampled to 48 kHz to play. Multichannel and non-PCM passthrough are untested; the sink advertises 8-channel LPCM and only stereo has been used. See `47-hdmi-audio-cec.md`.

tiagoagueda closed this issue

2026-08-28 16:37:48 +00:00

tiagoagueda referenced this issue from a commit

2026-08-29 11:58:09 +00:00

HDMI audio and CEC, and the A15 cluster corrupting memory all along

tiagoagueda referenced this issue from a commit

2026-08-29 11:58:09 +00:00

Audio is audible, after two clock faults and an instrument I ignored

tiagoagueda referenced this issue from a commit

2026-08-29 12:07:51 +00:00

HDMI audio and CEC, and the A15 cluster corrupting memory all along

tiagoagueda referenced this issue from a commit