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?

What we thought was wrong

Before any of the chip-side fixes landed, the live theory was that FreeBSD’s PCM vchan (virtual-channel) mixer was not advancing data from its input clients into the hardware channel’s play_buf.

The other problems lived in the codec analog stage and on the board. The next section is what the chip-side instrumentation was hiding.

Update: the buffer wasn’t the problem

The vchan-feeds-zeros theory was wrong — or rather, only one symptom of a deeper problem. The samples did eventually flow. They flowed into a codec whose analog output stage had no power. They flowed through the wrong output mixer. And once the analog rails were up and the right pins were unmuted, fixing the chip-side path momentarily broke the very transport this essay is being written over.

/* DT: codec analog rails must come up at boot */
vcca3v0_codec: LDO_REG1 {
    regulator-always-on;
    regulator-boot-on;
    /* …existing min/max… */
};
vcca1v8_codec: LDO_REG3 {
    regulator-always-on;
    regulator-boot-on;
    /* …existing min/max… */
};

/* rt5640: route DAC1 → HP, not the muted reset default */
rt5640_write(sc, RT5640_HPO_MIXER, 0xa000);

/* rt5640: full Linux-mainline HP power-on sequence,
 * not the one-shot PWR_HA|HP_L|HP_R that left the amp biased badly */
/* depop pre-charge → drop FV1/FV2 → PWR_HA → settle 15ms →
 * restore FV1/FV2 → power HP_L|HP_R → DAPM HPO → pmu_depop */

&usbdrd_dwc3_0 {
    dr_mode = "peripheral";  /* was "host" — broke ssh on next DTB flash */
};

Postscript: the TLV that lied

The previous section closed on a7b237f — dr_mode flipped back to peripheral, SSH restored, “audio… plays.” It didn’t. SSH was back; the speaker was still silent. Every chip-side, DT-side, board-side fix from the last three weeks was in place and correct, and there was no sound from either the loudspeaker or the earpiece.

What followed was two more days of register-by-register comparison against the upstream Linux sound/soc/codecs/rt5640.c. Then an agent doing an exhaustive walk through that file found the bug. It was one register. It had been wrong since the very first init in 71fe3bf.

static const DECLARE_TLV_DB_MINMAX(dac_vol_tlv, -6562, 0);

rt5640_write(sc, RT5640_DAC1_DIG_VOL, 0x0000);

/* rt5640: DAC1_DIG_VOL — 0 is -65.6 dB, not 0 dB. Default is 0xafaf. */
-rt5640_write(sc, RT5640_DAC1_DIG_VOL, 0x0000);
+rt5640_write(sc, RT5640_DAC1_DIG_VOL, 0xafaf);

/* rt5640: SPO mixer routing — clear bit 11 not bit 13 to route SV → SPO. */
-rt5640_write(sc, RT5640_SPO_L_MIXER, 0xd800);
+rt5640_write(sc, RT5640_SPO_L_MIXER, 0xe800);
-rt5640_write(sc, RT5640_SPO_R_MIXER, 0x5800);
+rt5640_write(sc, RT5640_SPO_R_MIXER, 0x2800);

/* rt5640: PWR_DIG2 bit 15 is PWR_ADC_SF, not a DAC bit. Drop it. */
-rt5640_update_bits(sc, RT5640_PWR_DIG2, 0x8000, 0x8000);

Postscript: volume that lied

The next bug was less dramatic but more user-visible: music was recognizable, but the hardware volume buttons did not really attenuate the speaker.

Postscript: the amplifier that wasn’t enabled

After the TLV fix, the loudspeaker played — but only because the simple-audio-amplifier’s enable GPIO happened to drift HIGH during boot. A clean reboot would land it LOW and audio would silently fall back to inaudible. The DT had the amp node; the FreeBSD simple_amplifier driver attached; nothing was driving the GPIO on PCMTRIG.

What’s still open

• The proximity sensor and headphone-jack detect aren’t wired up.
• We don’t switch routing between speaker and headphones — the HPO path is on regardless of jack state.
• The earpiece (SPO) routing is now correct but the actual transduction hasn’t been validated end-to-end.
• Microphone capture isn’t wired to a DAPM walk yet.
• rt5640_dai_init still takes the codec mutex inside the I2C bus’s Giant path. Lock-order reversal, doesn’t crash, real.