I²S: ES8311 codec mic returns silent/constant samples on ESP32-S3 — regression between IDF v5.4.2 and v5.5.1 (IDFGH-17668)

[chilang]

Summary

Microphone capture via I²S from an ES8311 audio codec on ESP32-S3 returns silent / constant samples (-8 or -1 repeating) on ESP-IDF v5.5.1, but works correctly on v5.4.2. Identical application source, identical codec init sequence, identical hardware. Bisect scope is coarse (just two release tags) — sharing in case the I²S driver / MCLK-routing team can narrow it.

Hardware

• M5Stack Cardputer-Adv (ESP32-S3-FN8 + ES8311 codec on I²C bus 0, addr 0x18)
• I²S pins: BCK=GPIO41, WS=GPIO43, ADC_SDOUT=GPIO46, DAC_SDIN=GPIO42
• MCLK: routed via GPIO matrix (specific pin determined by mclk_multiple=256 × fs)

Reproduction

Standalone ESP-IDF project using M5Unified 0.2.10's Mic_Class (legacy i2s_driver_install API path) with the documented ES8311 init for Cardputer-Adv. Same source compiled against two IDF versions:

ESP-IDF	Result
v5.4.2	✅ ADC outputs real audio, sample min/max track sound
v5.5.1	❌ ADC outputs constant -8 (s16le) regardless of audio input

In both builds:

• I²C reaches the codec (writes ack, reads back as written)
• After Mic.begin(), the ES8311 is in correct ADC mode: 0x01=0xBA (mic clock manager), 0x0E=0x02 (ADC modulator ON), 0x14=0x10 (MIC1 input), 0x17=0xBF, 0x1C=0x6A
• BCK and WS clocks are present on the I²S bus
• ASDOUT line carries data on v5.4.2 but not on v5.5.1

Symptoms are consistent with MCLK not reaching the codec on v5.5.1 (PLL can't lock without MCLK = 256×fs = 4.096 MHz, so the ADC outputs a DC-offset constant). I haven't been able to scope-probe the MCLK pin directly to confirm.

Hypothesis

Looks like a regression in either:

• The GPIO-matrix MCLK output assignment for ESP32-S3 in the I²S legacy driver wrapper, OR
• The MCLK derivation/divider path inside the I²S driver after the v5.4 → v5.5 refactor

I noticed M5Stack's own ES8311 "User Demo" firmware (a v5-era IDF build that ships on M5Burner) uses the new i2s_channel_* API (i2s_new_channel, i2s_std_set_clock, i2s_check_set_mclk) and works correctly. The Arduino M5Unified library still uses the legacy i2s_driver_install API and breaks on v5.5.1 — suggests the legacy shim's MCLK handling may have been broken or removed in v5.5 without that path being updated.

Workaround

Build against IDF v5.4.2.

For UIFlow MicroPython users on Cardputer-Adv I've opened a one-line PR pinning the patch series back to v5.4: m5stack/uiflow-micropython#97.

Environment

• ESP32-S3-FN8 (revision 0)
• IDF v5.4.2: ✅ works (tag v5.4.2)
• IDF v5.5.1: ❌ broken (tag v5.5.1)
• Audio codec: ES8311 (Everest Semi)
• Compiler: xtensa-esp32s3-elf-gcc shipped with each IDF version

What would help

• Confirm whether the I²S legacy driver MCLK pin routing changed between v5.4 and v5.5 on ESP32-S3
• If so, either fix the legacy path or document the migration requirement to the new i2s_channel_* API for ES8311 / I²S-codec workloads

Happy to run additional tests on this exact hardware (logic-analyzer probes on MCLK/BCK/WS, narrower commit bisect, repro on the new API for comparison) if it'd help triage.

[Vorrad]

Thanks for the detailed report.

To help narrow this down, could you please share a bit more information?

1. The relevant I2S and ES8311 configuration code, especially:
   • The i2s_config_t passed to i2s_driver_install()
   • The i2s_pin_config_t passed to i2s_set_pin()
   • Any ES8311 register init sequence or codec configuration code
   • The final sample rate, slot width, channel format, and mclk_multiple
2. If possible, please probe the I2S bus with an oscilloscope or logic analyzer on v5.4.2 and v5.5.1, and compare:
   • MCLK
   • BCLK
   • WS/LRCK
   • ES8311 ASDOUT / I2S data-in line

It would be especially helpful to know whether MCLK is present and at the expected frequency, and whether BCLK/WS look correct in both versions. If only one signal differs between v5.4.2 and v5.5.1, that should greatly reduce the search scope.

On my side, I've tried using legacy APIs in 5.5.1 to configure the RX channel, and the MCLK works correctly so far.

And by the way, it is recommended to use the new version of the I2S driver (under path components/esp_driver_i2s) instead of the legacy one, which has better stability and long term maintainance.