No audio from built-in PAD7 stereo speakers on CB1 Debian13 kernel 7.0 (V3.1.0); works on the 5.16 BSP image
- Dominant language
- No language data
- Stars
- 496
- Forks
- 86
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
On the CB1 Debian13 / kernel 7.0 image (release V3.1.0) the built-in stereo
speakers of the BIGTREETECH PAD7 stay silent. The same hardware produces sound on
the older 5.16 BSP image. On 7.0 the digital audio chain looks complete end to end
(the PCM runs), but nothing reaches the speakers.
## Environment
- Image: CB1_Debian13_minimal_kernel7.0_20260430 (release V3.1.0). Likely also
relevant to the Klipper variant of the same release.
- Kernel: 7.0.2-vendor-sunxi64
- Board: CB1 on a PAD7 carrier (model "BigTreeTech CB1",
fdtfile sun50i-h616-bigtreetech-cb1-sd.dtb), overlays=hdmi (default)
## Audio hardware path (from the PD7 V1.0 schematic)
CB1 HDMI out -> LT8619C (HDMI receiver, de-embeds I2S) -> CS4344 I2S DAC (U19)
-> amplifier -> stereo speakers (the CS4344 drives left/right via AOUTL/AOUTR).
- CS4344 needs MCLK and shares the I2S bus with the LT8619C (net "I2S0":
SD0/SCLK/WS/MCLK), so the speakers are fed from the HDMI-embedded audio via the
bridge, not from a SoC GPIO I2S directly.
- The LT8619C is configured by the onboard HT32F0008 MCU (the 04d9:8030 USB-HID
"BTT-HDMI7" device, also the touch controller). It is not on any I2C the kernel
can see, so it is configured the same regardless of host OS.
## Works vs does not
- 5.16 BSP image: speakers work. Audio runs through the "sndahub" ALSA card
(sunxi-ahub-machine + DAM routing matrix; mixer has I2SxOUT switches).
- 7.0 (V3.1.0): the hdmi overlay enables ahub_dam_plat + ahub1_plat + ahub1_mach,
giving ALSA cards "Codec" (hw:0,0) and "HDMI" (hw:1,0, device
ahub_plat-i2s-hifi). There is no sndahub/DAM card and no DAM routing controls
(only "loopback debug" on the HDMI card).
## What we tried on 7.0 (all reproduced from the official build)
- hdmi overlay active (default).
- Installed inithdmiaudio + libtinyalsa.so + hdmi-audio.service from
bigtreetech/build (packages/blobs/sunxi/h616 and packages/bsp/sunxi).
- Restored asound.state.bigtreetech-cb1 (Codec: DAC 63, Line Out 31, switches on,
route Stereo; matches defaults).
- Played with both "aplay -D plughw:1,0 " and "inithdmiaudio -D 1".
Result every time: PCM goes RUNNING (S16_LE, 48000, 2ch), audio clocks up
(pll-audio-*, audio-hub, bus-audio-hub), DMA active, but no sound from the
speakers. (For completeness: rerouting the ahub to the SoC i2s3 pins PH5-PH8 is
the wrong layer; those GPIO pins do not feed the CS4344, the bridge does.)
## Likely difference
On 7.0 the digital chain is complete but silent. Compared to 5.16, the missing
piece looks like the ahub/DAM routing: 5.16 brings up the sunxi-ahub-machine + DAM
card that routes audio to the I2S the bridge/DAC consume, while the 7.0 BSP-audio
model (sunxi-snd-mach / sunxi-snd-plat-ahub) does not expose an equivalent
DAM-routed card. The LT8619C bridge itself is not the problem.
## What would help
- Is HDMI audio (and thus the built-in stereo speakers via the LT8619C) expected
to work on the 7.0 image? If so, the exact ALSA device plus any service/mixer
needed.
- If it depends on the 5.16 ahub/DAM machine, a pointer to the equivalent 7.0
device-tree/machine config, or confirmation it is not yet ported.
Happy to provide more logs (dmesg, /proc/asound, clk_summary, pinmux) if useful.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by comparing the 5.16 sndahub/ DAM setup with the 7.0 hdmi overlay and the ahub_dam_plat, ahub1_plat, and ahub1_mach configuration. Inspect the ALSA cards and controls with /proc/asound and amixer, then review the inithdmiaudio package, hdmi-audio.service, and device-tree or machine configuration. Done means identifying the missing route or confirming that the equivalent 7.0 configuration is not ported and documenting the required device and service.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- embedded-iot, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100