Add support for dual I²S microphones on ESP32/ESP32-S3 (stereo or dual independent input)

[kitopopo]

Description:
Currently, ESPHome only supports a single i2s_audio instance with one I²S microphone.
This limits setups where the hardware includes two I²S MEMS microphones — for example, for stereo capture, beamforming, or directional voice detection.

Context:
I am using an ESP32-S3 DevKitC-1 configured as a voice assistant device with wake word and voice recognition, using a configuration like this:

i2s_audio:

• id: i2s_in
  i2s_lrclk_pin: GPIO3
  i2s_bclk_pin: GPIO2

microphone:

• platform: i2s_audio
  id: va_mic
  i2s_audio_id: i2s_in
  i2s_din_pin: GPIO4
  channel: left
  bits_per_sample: 32bit

This setup works perfectly with one microphone (INMP441 or ICS-43434), but adding a second microphone with another i2s_din_pin is not possible.
The microphone platform in ESPHome does not support multiple instances or multi-channel capture, and the firmware will either fail to initialize or throw a conflict error because i2s_driver_install() allows only one active I²S instance.

---

Goal:
Enable ESPHome to use two I²S microphones simultaneously, in one of the following ways:

1. True stereo mode, reading left and right channels from a single I²S bus.

2. Two independent microphones, each with a different i2s_din_pin, possibly on different I²S peripherals.

This would unlock features such as:

Directional or beamforming voice capture.

More robust wake word detection in noisy environments (e.g., when a TV is on).

Multi-channel noise reduction or echo cancellation.

---

Technical observations:

The ESP32-S3 has two I²S peripherals (I2S0 and I2S1), both capable of RX operation.

The ESP-IDF framework allows assigning a different mic to each peripheral.

ESPHome’s i2s_audio component could be extended to include an i2s_port: 0|1 option to support multiple instances.

Currently, I2SAudioComponent registers globally and prevents more than one driver installation.

The voice_assistant and micro_wake_word pipelines could either merge or select one of the input streams.

---

Proposed example configuration:

i2s_audio:

• id: i2s_left
  i2s_port: 0
  i2s_lrclk_pin: GPIO3
  i2s_bclk_pin: GPIO2

• id: i2s_right
  i2s_port: 1
  i2s_lrclk_pin: GPIO14
  i2s_bclk_pin: GPIO15

microphone:

• platform: i2s_audio
  id: mic_left
  i2s_audio_id: i2s_left
  i2s_din_pin: GPIO4
  channel: left

• platform: i2s_audio
  id: mic_right
  i2s_audio_id: i2s_right
  i2s_din_pin: GPIO5
  channel: right

This would allow both microphones to work in parallel, providing either independent or combined audio streams.

---

Practical benefit:
In setups using voice_assistant and micro_wake_word, performance in noisy rooms (like when a TV is on) drops significantly with a single mic.
Using dual I²S microphones would greatly improve voice detection reliability and wake word recognition.

---

Summary of proposal:

Add support for multiple i2s_audio instances in RX mode.

Allow defining separate i2s_port and i2s_din_pin values per instance.

Optionally, provide a “stereo merge” option to combine both into one microphone stream.

---

References:

ESP-IDF I2S driver documentation

ICS-43434 datasheet

INMP441 datasheet

ESPHome i2s_audio component

ESPHome microphone platform

---

Final comment:
This feature would be especially useful for ESPHome-based wake word + voice assistant setups, improving reliability and noise resilience without needing external microphone arrays like ReSpeaker or other specialized hardware.

[kitopopo]

Hi everyone,
I am following up on this discussion, as it has been open for quite some time and there has been no response so far.
Support for dual I²S microphones on ESP32 / ESP32-S3 (stereo or independent inputs) would be very useful for several use cases, especially with the voice_assistant component and newer ESP32 boards.
ESPHome is evolving very quickly with frequent releases, so I wanted to ask whether this is something that could be considered, discussed, or at least clarified (even if the answer is that it is not planned).
Would it be better to move this discussion to a feature request issue so it can be tracked properly?
Please let us know what the preferred process is.
Any feedback or status update would be appreciated.
Thank you for your time.