A detailed schematic review revealed the source of the problem.
All three components — Core2, Audio Module, and Bottom2 — are interconnected through the shared M5 BUS.
The Bottom2 module includes a SPM1423 MEMS microphone, which uses:

GPIO0 (BUS pin 24) for the clock signal (CLK)
GPIO34 (BUS pin 26) for the data signal (DAT, digital output)

The Audio Module, based on the ES8388 codec, uses:

GPIO0 (BUS pin 24) for I2S_MCLK
GPIO34 (BUS pin 26) for I2S_MAIN_DIN

This creates a fundamental hardware conflict on the I2S bus.

The Core Conflict

Two independent devices attempt to drive the same data line:

The ES8388 (M144 Audio Module) uses GPIO34 to send digitized audio data from its ADC (line-in or microphone) to the ESP32 via I2S.
The SPM1423 (Bottom2) uses the same GPIO34 to output PDM audio data from its internal MEMS microphone.

From the ESP32’s perspective:

GPIO34 is input-only

However, on the physical PCB traces, both devices are electrically connected to this same line and actively drive it.
This results in a classic and severe bus contention scenario:

Two outputs connected together

• No arbitration
• No isolation
• No possibility for coexistence

Why This Cannot Be Solved in Software

At first glance, one might consider disabling the microphone via software. Unfortunately, this is not feasible due to both architectural and hardware constraints.
The Bottom2 doesn’t expose the SPM1423 MEMS dedicated enable/disable (chip select) pin.
The only way to silence it — effectively forcing its data output into a high-impedance (Hi-Z) state — is to stop its clock signal on GPIO0.
This leads directly to a deadlock:
If the M144 switch is set to position A:
GPIO0 is used as MCLK (mandatory master clock for ES8388 operation, typically 12.288 MHz)

If the switch is set to position B:
GPIO0 becomes I2S SCLK (bit clock)

Additionally:
The internal amplifier of the Core2 (NS4168) also uses GPIO0 for BCLK

In other words, GPIO0 is always actively used in any valid configuration.
Stopping the clock to disable the microphone would simultaneously break:

• the ES8388 codec
• or the Core2 internal audio path

Thus, there is no viable way to control the microphone via software without disrupting essential system functionality.

Design Oversight

The A/B switch on the M144 Audio Module was clearly designed to avoid clock conflicts (MCLK vs SCLK) with other peripherals.
However, the design completely overlooks the data line conflict on GPIO34.
This is particularly problematic because:

• the Bottom2 module is an official M5Stack accessory
• the SPM1423 microphone is always active by default
• both modules are intended to be used within the same ecosystem

Despite this, their coexistence leads to a non-functional configuration when using the ES8388 input path.

Conclusion

This issue is not a matter of configuration, firmware, or library incompatibility. It is a fundamental hardware design conflict on the shared M5 BUS.
When Bottom2 is attached:

• the SPM1423 microphone continuously drives the I2S data line
• the ES8388 is unable to deliver valid audio data
• the result is severe noise and corrupted signal

There is no reliable software workaround.
The only effective solutions are hardware-level:

• physically removing or isolating the SPM1423 microphone
• redesigning the Bottom2 PCB to include a switch or gating mechanism
• routing the microphone control (e.g., SELECT or enable logic) to a dedicated GPIO

Until such changes are implemented, the ES8388 input functionality cannot be used in conjunction with the Bottom2 module in a stable and predictable way.
My solution was to remove the SPM1423 Microphone from the PCB.
Another solution is to cut the relevant pins from the Bottom2 BUS with the same effect - removing SPM1423 from the circuit.