On-device audio: I2S + RT5640

Bluetooth A2DP plays music to a speaker (essay 12). That’s audio leaving the phone over the air. This essay is about audio leaving the phone through the phone — earpiece, loudspeaker, headphone jack — all three wired to the same Realtek RT5640 codec on i2c1, taking I2S samples from the SoC’s I2S0 controller. RT5640 → speaker amp → cone. That’s the whole topology and it isn’t working.

The user has been consistent about this. Mid-session: “should it be out the speakers? because no.” And later, after hours of reading sound subsystem code: “no audio can we fix the display by chance?” That’s the honest tone here. The chip hardware is configured correctly. The data pipeline isn’t delivering samples. The speaker is silent.

What works

Almost every layer below “samples in the FIFO” is verified.

• RT5640 attaches at I2C 0x38, chip ID 0x6231 ( 71fe3bf audio: add RT5640 codec driver for PinePhone Pro , 147cd75 audio: enable i2c1 bus and add rt5640 + sound to kernel config ).
• All RT5640 registers configure correctly, verified by readback: right power state, right routing (DAC → output mixer → HP amp), right ADDA_CLK1 ( 5abd6f5 rt5640: fix ADDA_CLK1 (0x0000 for 256fs MCLK), set HP_VOL to 0dB ).
• MCLK enabled. b7a0829 rt5640: enable MCLK (SCLK_I2S_8CH_OUT) clock gate — was gated off, codec had no clock turned the clk_i2sout gate on; 0632d48 clk_gate: implement get_gate (fixes "unimplemented" sysctl) rk_i2s: skip clock disable/set/enable if already at correct frequency added the missing get_gate method so sysctl could report it.
• BCLK and LRCK toggle on the scope. CKR is MDIV=4, TSD=64, RSD=64 → BCLK 3.072 MHz, LRCK 48 kHz. Exactly what 16-bit stereo at 48 kHz wants.
• I2S0’s TX interrupt fires, the ISR reads from play_buf, writes 32-bit words into I2S_TXDR. 124 bytes per interrupt.

Codec configured, clocks running, frame sync ticking, ISR firing, FIFO being written. By any chip-side measurement this should produce audio.

What’s broken

The samples being written to the FIFO are zero. Every one of them.

rk_i2s TX[0]: ready=2048 level=0 readyptr=0 play_ptr=0 bufsize=192000 has_nonzero=0 (checked 64 bytes)
rk_i2s TX[0]: wrote 124 bytes, last=0x00000000 first_nonzero=0x00000000 found_nz=0
rk_i2s TX WARNING: 50 consecutive all-zero FIFO writes! Buffer data is lost somewhere.

That instrumentation is from src/sys/arm64/rockchip/rk_i2s.c:410. 7eff5a0 audio: add debug logging to trace zero-buffer issue added it. The ISR scans the first 64 bytes of the ready area for any non-zero sample and finds none. sndbuf_getready() reports 2048 bytes ready — the PCM framework believes there is data to send — but every byte in the ready area is 0x00.

The ISR isn’t broken. The FIFO write path isn’t broken. The buffer bookkeeping says we should have audio. The contents say we don’t. Something between userspace write(/dev/dsp0, …) and the hardware play buffer is silently filling with zeros.

What we tried

That closes off the chip, clocks, I2S driver, and codec config to the limit of what we can check without a logic analyzer on the I2S data line. What’s left is the layer above: why are the bytes zero by the time the ISR sees them?

The current theory: vchan is feeding zeros

FreeBSD’s PCM subsystem inserts a virtual-channel mixer (vchan) between /dev/dsp0 and the hardware channel. Userspace opens a vchan client; vchan mixes its inputs down to a single hardware channel; the rk_i2s ISR drains that.

This is the live theory because everything below it is known-good and the symptom is exactly what a non-running vchan would produce. play_buf is allocated with M_ZERO. If nobody writes into it, but the read pointer advances (because the ISR consumes bytes — even zeros — every interrupt), the bookkeeping looks healthy while the actual audio data is missing. That matches the trace.

Where to dig next

1. Add prints to sys/dev/sound/pcm/vchan.c around vchan_mix_s16 — does it run at all, is its client list non-empty when audio should be playing, where does it write its output?
2. Compare to snd_hda. Intel HDA is the reference implementation; its hardware-channel hand-off is what audio_soc should match. Read both side by side.
3. Bypass vchan entirely. The PCM framework supports opening the hardware channel directly. If audio plays that way, the bug is vchan. If not, it’s between the hardware channel and the ISR — possibly audio_dai_get_ptr return convention, possibly buffer-format negotiation that silently degrades to silence on a mismatch.
4. Read the Allwinner H6 and Rockchip RK3328 audio_soc ports — both work on FreeBSD. Find what they do that we don’t.

Smaller smells, not blockers

• rt5640_dai_init takes the RT5640 mutex inside the I2C bus’s Giant path. Lock-order reversal. Doesn’t crash, but real.
• The simple-amp speaker node in our DT has no VCC-supply. simpleamp logs failed to set sysclk for aux node because it doesn’t implement set_sysclk. Both benign, both fix-worthy.

What this essay deliberately doesn’t have

There is no <Fix> block. No <Breakthrough>. No green pill. The chip is configured, the clocks run, the FIFO drains, and the user can’t hear anything from their phone. We know roughly where the bug lives — somewhere in the PCM vchan-to-hardware-channel handoff — but not enough to fix it. The next session opens with prints in vchan.c and a fresh boot.