Skip to content

AudioReactive UDP Send causes high ping latency and slow web UI on ESP32 #5904

Open

Description

@cavox

What happened?

Enabling AudioReactive UDP Sound Sync “Send” causes significant network latency and makes the WLED web interface slow, sometimes displaying “Connection to light failed”.

Hardware and network:
ESP32 DevKit V1 / ESP32-WROOM-32, 4 MB flash, CPU 240 MHz
INMP441 I2S microphone
54 SK6812 RGBW LEDs
Freebox Delta Wi-Fi access point
Wi-Fi signal approximately −55 dBm / 90%
“Disable WiFi sleep” enabled

Versions tested:
16.0.1, build 2606300: problem occurs
0.15.4: slightly better, but problem persists
17.0.0-dev “Kagayaki”, build 2607170: slightly better, but problem persists

To Reproduce Bug

Enable AudioReactive with the local I2S microphone.
Set audio sync to Off: web UI and ping are stable.
Set audio sync to Send, port 11988.
Close the web interface and continuously ping the ESP32: latency becomes irregular.
Earlier testing showed ping times exceeding 1,000 ms and occasional timeouts. The exact latency statistics have not yet been collected for each version.

Expected Behavior

Sending audio sync packets should not cause significant ping latency or make the web UI unresponsive.
Is there a known issue with AudioReactive UDP transmission, or any recommended diagnostic logging to distinguish a firmware issue from a Wi-Fi multicast interaction?

Install Method

Binary from WLED.me

What version of WLED?

16.0.1, build 2606300 & 17.0.0-dev

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

Uptime does not reset: no reboot observed.
AudioReactive works normally with sync Off.

Disabling the Node-RED receiving flow does not resolve the issue.
The problem occurs even with the WLED web interface closed.
With Send active, the latest Info shows “send mode (unconnected)”, 112.3 kB free heap and an average LED frame rate of 43 FPS.
Node-RED normally receives the multicast audio packets to control another RGB light through Home Assistant.
No alternative access point has been tested, so an interaction with the Freebox Delta or Wi-Fi multicast handling remains possible.

Code of Conduct

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

Activity

  1. DedeHai commented on Oct 14, 2026

    @DedeHai
    Collaborator

    −55 dBm is quite a bad signal, most devices I have do not even work below -60dB (meaning you may be at the "it barely works" region and flooding the network with sync packets tips you over the edge). If you want to call this a bug: check if it works if you put everything close to your router, otherwise I would call it "bad wifi"

  2. cavox commented on Oct 14, 2026

    @cavox
    Author

    -55 dBm is not so bad and is better than -60dBm.

  3. DedeHai commented on Oct 14, 2026

    @DedeHai
    Collaborator

    3. -55 dBm is not so bad and is better than -60dBm.

    it can be bad and yes I am aware how dB works. You say it's a bug, I say it can also be bad wifi - because I personally tested exactly this case a while back and it worked like a charm. So please test and rule out bad wifi.

  4. cavox commented on Oct 14, 2026

    @cavox
    Author

    ok, thx for your feedback

  5. added
    cannot reproduceDevelopers are not able reproduce. Might be fixed already, or report is missing important details
    on Oct 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugcannot reproduceDevelopers are not able reproduce. Might be fixed already, or report is missing important detailswaiting for feedbackaddition information needed to better understand the issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions