AudioReactive extremely oversensitive with digital I2S mic (INMP441)

[Jibeji]

What happened?

AudioReactive with a digital I2S mic (INMP441, ESP32-WROOM-32) triggers on almost any ambient noise even with Squelch at 255 and Gain at 0, in a quiet room. Hardware causes (board, mic unit, wiring, power supply, LED strip, DMX) were ruled out through extensive isolated testing (happy to share details on request).

The key finding: on the exact same board/mic/wiring, a standalone test using the legacy I2S driver (driver/i2s.h, same as audio_source.h/I2SSource in the audioreactive usermod) reproduces the bug — readings stay near full scale even in silence. Rebuilding the same test with the new i2s_std driver (Arduino ESP_I2S API), no hardware changes, gives normal readings: low at rest, proportional spikes on real sound. This points to the legacy I2S driver itself rather than hardware, which lines up with the existing comment in audio_reactive.cpp noting audioreactive hasn't been ported to driver/i2s_std.h yet.

Is this a known limitation of the legacy driver, and would the planned i2s_std migration fix it?

To Reproduce Bug

1. Wire an INMP441 to an ESP32-WROOM-32 (standard SD/WS/SCK, L/R to GND).
2. WLED v16.0.1, official binary. Enable AudioReactive with a generic I2S digital mic, matching pins.
3. Gain = 0, Squelch = 255, AGC off.
4. In a quiet room, observe the audio level / LEDs.

Expected Behavior

With Squelch at 255, AudioReactive should stay inactive in a quiet room. Instead it reacts continuously, regardless of Squelch/Gain/AGC.

Install Method

Binary from WLED.me

What version of WLED?

16.0.1

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[softhack007]

@Jibeji interesting finding - normally the INMP441 should work well with gain=50, squelch=5, AGC normal. I fact I've only seen this high noise level when the WS/SCK wires are swaped.

Is this a known limitation of the legacy driver, and would the planned i2s_std migration fix it?

We are planning to use the newer driver in future, however I am not aware of any problems with the legacy driver.

• update AR usermod with proper V5 support (new API) #5764

[Jibeji]

@softhack007 Thanks for the quick reply!

I tried swapping WS/SCK as you suggested — with them swapped, AudioReactive goes completely dead (no reaction at all), so the original wiring (SCK=25, WS=33) is correct. That rules out a wiring swap.

A bit more on how I got here, since it wasn't just a hunch: I went through the usual suspects one by one before suspecting the driver — DMA/partial reads, mono/stereo format, RS485/DMX (wired and unwired), power supply (mains vs. powerbank), LED strip disconnected, mic physically covered, WiFi never enabled in the isolated test, decoupling cap placement. The mic still showed the same "pinned near max even in total silence" behavior — both live in WLED and in a standalone test sketch using the legacy driver/i2s.h, same wiring.

Then, still on the exact same board and wiring (no rewiring), I rebuilt that standalone test with the new Arduino ESP_I2S API (i2s_std) instead of the legacy driver, and got a clean, quiet-appropriate baseline that responds proportionally to real sound (e.g. a hand clap spikes it, then it decays back down) — first time in this whole process that behavior looked normal.

So with wiring now also confirmed correct, the legacy-vs-i2s_std comparison is the one piece of evidence I can't explain away. Given #5764, does that match anything you've seen while working on the V5 port, or is it worth digging into further on my end (happy to test a build against that PR if useful)?

[DedeHai]

@Jibeji testing of the PR branch would definitely be helpful - I only briefly tested it but did not do any direct A - B comparison of raw values. That PR is also kind of "obsolete" as the way forward is to build against MM usermod. I had an AI port all changes from #5764 - but I did not yet have time to do a review on that, that will take quite some time going through all that code. I did test it though and it compiles and works with I2S as well as analog, both in float and integer math.