Full-duplex I2S on the CoreS3, without clicks or clipped vowels.

Companion's reference platform during early development is the M5Stack CoreS3. On the TX side of I2S0 is an AW88298 speaker amplifier; on the RX side is an ES7210 four-channel ADC. They share the same bit clock, the same word select, and the same I2S peripheral, configured as full duplex. The datasheets make this sound like a checkbox. It is not.

One bus, two directions, zero drift

Duplex on a single I2S peripheral means the AW88298 and the ES7210 have to agree on sample rate and bit width down to the cycle. We run 16 kHz mono 16-bit in both directions — the same format every other audio path in CareOS uses. If TX and RX disagree by even a fractional clock, the codec slips a sample every few seconds and you hear it as a faint tick under the voice. The fix is to drive BCLK and WS from one master (the ESP32-S3) and let both chips slave off it.

The DMA descriptor rings live in PSRAM, not internal SRAM, because we need enough buffering — eight descriptors of 1024 bytes each per direction — to ride out a 5-10 ms hiccup when the realtime WebSocket task preempts the audio task. CPU-driven i2s_read / i2s_write would burn an entire core just shuffling bytes. DMA hands us full buffers on a queue and the audio task only wakes when there is real work.

Why the failure mode matters

A buffer underrun on TX is a click. A clock skew on RX is a clipped s or t — exactly the consonants that carry meaning in yes, stop, help. Get duplex wrong and the resident hears a stuttering robot, and the model upstream hears mush. Get it right and the bedside conversation feels like one.

With the bus stable, the next layer is acoustic echo cancellation, so the resident can talk over Companion mid-sentence and be heard. Duplex I2S is what makes barge-in possible at all — the mic is already live while the speaker is playing. AEC is the work ahead. The clean bus is the foundation it sits on.