LED delay on HyperHDR ambilight

[withay]

What happened?

I updated to WLED 16 on my HyperHRD ambilight (WLED on an ESP32, HyperHDR on a Pi) and the leds lag behind the video about a full second.

To Reproduce Bug

I just updated to 16 and noticed immediately.

Expected Behavior

Prior to the update, the leds reacted to the video almost simultaneously.

Install Method

Binary from WLED.me

What version of WLED?

WLED 16.0.0

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

I rolled back to 15.3 and it is working correctly again.

Code of Conduct

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

[softhack007]

@withay can you measure the ping time from your PI to the WLED instance? Part of the delay may be network latency 🤔

[withay]

No video playing:

PING 10.69.0.xxx (10.69.0.xxx) 56(84) bytes of data.
64 bytes from 10.69.0.125: icmp_seq=1 ttl=255 time=16.1 ms
64 bytes from 10.69.0.125: icmp_seq=2 ttl=255 time=8.36 ms
64 bytes from 10.69.0.125: icmp_seq=3 ttl=255 time=13.5 ms
64 bytes from 10.69.0.125: icmp_seq=4 ttl=255 time=9.84 ms
64 bytes from 10.69.0.125: icmp_seq=5 ttl=255 time=15.1 ms
64 bytes from 10.69.0.125: icmp_seq=6 ttl=255 time=9.71 ms
64 bytes from 10.69.0.125: icmp_seq=7 ttl=255 time=7.07 ms
64 bytes from 10.69.0.125: icmp_seq=8 ttl=255 time=5.84 ms
64 bytes from 10.69.0.125: icmp_seq=9 ttl=255 time=9.49 ms
64 bytes from 10.69.0.125: icmp_seq=10 ttl=255 time=10.2 ms

--- 10.69.0.xxx ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 5.835/10.518/16.075/3.191 ms

[withay]

That was with it off, this is with a movie playing:

PING 10.69.0.xxx (10.69.0.xxx) 56(84) bytes of data.
64 bytes from 10.69.0.125: icmp_seq=1 ttl=255 time=5.61 ms
64 bytes from 10.69.0.125: icmp_seq=2 ttl=255 time=10.7 ms
64 bytes from 10.69.0.125: icmp_seq=3 ttl=255 time=4.30 ms
64 bytes from 10.69.0.125: icmp_seq=4 ttl=255 time=8.60 ms
64 bytes from 10.69.0.125: icmp_seq=5 ttl=255 time=13.8 ms
64 bytes from 10.69.0.125: icmp_seq=6 ttl=255 time=11.8 ms
64 bytes from 10.69.0.125: icmp_seq=7 ttl=255 time=25.2 ms
64 bytes from 10.69.0.125: icmp_seq=8 ttl=255 time=18.7 ms
64 bytes from 10.69.0.125: icmp_seq=9 ttl=255 time=27.8 ms
64 bytes from 10.69.0.125: icmp_seq=10 ttl=255 time=45.5 ms

--- 10.69.0.xxx ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 4.301/17.198/45.528/11.994 ms

[DedeHai]

There were several reports about this on discord. Since the ESP has only a single frame buffer the data must be piling on the sender side. I saw no such delays using DDP.

[DedeHai]

The real question is where does the data get stuck and why

[softhack007]

In theory - as ESPAsyncE131 is based on AsyncUDP - it's possible that UDP packets queue up on the esp32 side.

However this could only happen when

• the sender is faster (framerate) than the receiving esp32 can handle
• the udp/network input queue was already very full (congestion) when starting real-time mode
• the esp32 is too busy with other tasks (WiFi ? RMT interrupts?) so the AsyncUDP task is staved of CPU time
• "Use main segment only" might cause slowdowns in the "realtime receive" mode
• priority inversion (lower prio task hogs on a resource need by a higher prio task)

I don't think that any of these were newly introduces in 16.0.0. In case that a classic ESP32 shows these problems, it could be something deep in the newer arduino-esp32/esp-idf frameworks because these were upgraded on classic ESP32.

[softhack007]

@coderabbitai with respect to #5575 (comment) : what is the AsyncUDP packet queue size? Was the queue size changed between WLED 16.0.0 and WLED 0.15.4 ?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for AsyncUDP queue size references in WLED codebase
rg -rn "queue" --include="*.h" --include="*.cpp" -i | grep -i "udp\|async\|e131\|ddp" | head -60

# Search for any AsyncUDP config or queue size defines
rg -rn "ASYNC_UDP\|asyncudp\|AsyncUDP" --include="*.h" --include="*.cpp" -i | head -60

# Check platformio.ini or similar for framework versions
cat platformio.ini 2>/dev/null | head -80 || true

# Check for any queue size defines related to UDP
rg -rn "queue_size\|QUEUE_SIZE\|UDP_QUEUE\|udp_queue" --include="*.h" --include="*.cpp" --include="*.ini" -i | head -40

Length of output: 4915

---

🏁 Script executed:

#!/bin/bash
# Fix rg commands - use -g for glob patterns
rg -rn "queue" -g "*.h" -g "*.cpp" | grep -i "udp\|async\|e131\|ddp" | head -60

# Search for AsyncUDP references
rg -rn "AsyncUDP" -g "*.h" -g "*.cpp" | head -40

# Check git tags related to versions
git tag | grep -E "v?0\.15\.4|v?16\.0" | head -20

# Check platformio.ini for arduino-esp32 framework version
grep -i "platform\|framework\|arduino" platformio.ini | head -40

# Look for library dependencies - ESPAsyncE131, AsyncUDP versions
cat wled00/library.json 2>/dev/null || true
find . -name "library.json" | head -10 | xargs grep -l "AsyncUDP\|E131" 2>/dev/null | head -5
find . -name "*.ini" | xargs grep -l "AsyncUDP\|ESPAsyncE131\|e131" 2>/dev/null | head -5

# Check lib_deps in platformio.ini
grep -A 100 "lib_deps" platformio.ini | head -60

Length of output: 5716

---

🌐 Web query:

AsyncUDP esp32 arduino packet queue size CONFIG_LWIP_UDP_RECVMBOX_SIZE

💡 Result:

What CONFIG_LWIP_UDP_RECVMBOX_SIZE actually controls

In ESP-IDF/lwIP, CONFIG_LWIP_UDP_RECVMBOX_SIZE is the maximum number of received UDP packets that lwIP will queue (“mailbox”) per UDP netconn/socket (i.e., for the netconn / BSD sockets layers). If packets arrive faster than your app reads them, this queue can fill and packets will be dropped. Espressif’s Kconfig help text describes it as the max cached UDP packets per UDP socket. (docs.espressif.com)

Does it affect Arduino AsyncUDP?

Usually, no. Arduino-ESP32’s AsyncUDP uses lwIP’s raw UDP API (udp_pcb + udp_recv) and then forwards packets into its own FreeRTOS queue, so CONFIG_LWIP_UDP_RECVMBOX_SIZE (netconn mailbox) isn’t the knob that limits AsyncUDP buffering. (github.com)

The real AsyncUDP “packet queue size” (Arduino core)

In current arduino-esp32 AsyncUDP.cpp, the internal queue is created as:

• xQueueCreate(32, sizeof(lwip_event_packet_t *))

So the AsyncUDP packet event queue depth is 32 (unless your core version differs). (github.com)

How to change either one (practical notes)

• In Arduino IDE with the precompiled core, changing sdkconfig/sdkconfig.h in the core tree generally won’t change these options in the binaries you’re using. (espressif-docs.readthedocs-hosted.com)
• To increase buffering for AsyncUDP, you typically must patch/rebuild the Arduino core (change the 32 in AsyncUDP.cpp) or build Arduino as an ESP-IDF component and set options there. (github.com)
• To increase buffering for BSD sockets / WiFiUDP-style code, you’d change CONFIG_LWIP_UDP_RECVMBOX_SIZE in an ESP-IDF build (trade-off: more RAM; potentially better throughput). (espressif-docs.readthedocs-hosted.com)

Citations:

• 1: https://docs.espressif.com/projects/esp-idf/en/v3.3.1/api-reference/kconfig.html?utm_source=openai
• 2: https://github.com/espressif/arduino-esp32/blob/master/libraries/AsyncUDP/src/AsyncUDP.cpp
• 3: https://github.com/espressif/arduino-esp32/blob/master/libraries/AsyncUDP/src/AsyncUDP.cpp
• 4: https://espressif-docs.readthedocs-hosted.com/projects/arduino-esp32/en/latest/faq.html?utm_source=openai
• 5: https://github.com/espressif/arduino-esp32/blob/master/libraries/AsyncUDP/src/AsyncUDP.cpp
• 6: https://espressif-docs.readthedocs-hosted.com/projects/esp-idf/en/latest/api-guides/lwip.html?utm_source=openai

---

🏁 Script executed:

#!/bin/bash
# Check git tags for WLED versions
git tag | sort | tail -30

# Check esp32 platform version in platformio.ini
grep -A 5 "\[esp32\]" platformio.ini | head -30

# Get the esp32 platform/arduino-esp32 version
grep -i "espressif32\|arduino-esp32\|platform_esp32\|esp32_idf" platformio.ini | head -20

# Check what version was used in 0.15.x tag
git show v0.15.4:platformio.ini 2>/dev/null | grep -i "espressif32\|platform_esp32\|arduino-esp32" | head -20 || \
git show 0.15.4:platformio.ini 2>/dev/null | grep -i "espressif32\|platform_esp32\|arduino-esp32" | head -20

# Check what version is used in 16.0.0 tag  
git show v16.0.0:platformio.ini 2>/dev/null | grep -i "espressif32\|platform_esp32\|arduino-esp32" | head -20 || \
git show 16.0.0:platformio.ini 2>/dev/null | grep -i "espressif32\|platform_esp32\|arduino-esp32" | head -20

Length of output: 1223

---

🌐 Web query:

arduino-esp32 AsyncUDP queue size history change xQueueCreate 32

💡 Result:

In espressif/arduino-esp32’s AsyncUDP library, the internal receive-task queue length has been hard-coded to 32 (_udp_queue = xQueueCreate(32, sizeof(...))) and, based on the repo history, it was already 32 when AsyncUDP was first added and remains 32 on master today. The more recent AsyncUDP changes (e.g., making the UDP task stack size configurable) did not change this queue length. [1] [2] [3]

Sources:
[1] Current master AsyncUDP.cpp showing xQueueCreate(32, ...)
[2] Initial AsyncUDP add (commit a59eafb, Jun 27, 2018) showing xQueueCreate(32, ...)
[3] Commit message for a59eafb indicating “Add initial AsyncUDP”

---

🏁 Script executed:

#!/bin/bash
# List all tags to find the right tag name
git tag | sort

# Check esp32 platform details for 0.15.4
git show v0.15.4:platformio.ini 2>/dev/null | grep -i "esp32_idf\|espressif32\|tasmota\|arduino-esp32\|idf" | head -30

# Check esp32 platform details for v16.0.0
git show v16.0.0:platformio.ini 2>/dev/null | grep -i "esp32_idf\|espressif32\|tasmota\|arduino-esp32\|idf" | head -30

# Also check the full esp32_idf section for both tags
git show v0.15.4:platformio.ini 2>/dev/null | grep -A 10 "esp32_idf_V" | head -40
git show v16.0.0:platformio.ini 2>/dev/null | grep -A 10 "esp32_idf_V" | head -40

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# List GitHub releases to find the right tag names
gh release list --repo wled/WLED --limit 20

# Get platformio.ini content at tag v0.15.4
gh api repos/wled/WLED/contents/platformio.ini?ref=v0.15.4 --jq '.content' | base64 -d | grep -i "esp32_idf\|espressif32\|tasmota\|arduino-esp32\|idf" | head -20

# Get platformio.ini content at tag v16.0.0
gh api repos/wled/WLED/contents/platformio.ini?ref=v16.0.0 --jq '.content' | base64 -d | grep -i "esp32_idf\|espressif32\|tasmota\|arduino-esp32\|idf" | head -20

# Get esp32_idf_V section details from both
echo "=== 0.15.4 ==="
gh api repos/wled/WLED/contents/platformio.ini?ref=v0.15.4 --jq '.content' | base64 -d | grep -A 5 "esp32_idf_V\b" | head -30

echo "=== 16.0.0 ==="
gh api repos/wled/WLED/contents/platformio.ini?ref=v16.0.0 --jq '.content' | base64 -d | grep -A 5 "esp32_idf_V\b" | head -30

Length of output: 3896

---

@softhack007 Here's what I found:

AsyncUDP packet queue size

The AsyncUDP implementation in arduino-esp32 does not use CONFIG_LWIP_UDP_RECVMBOX_SIZE (the lwIP netconn mailbox). Instead, it uses lwIP's raw UDP API and forwards packets into its own internal FreeRTOS queue, created as xQueueCreate(32, sizeof(lwip_event_packet_t *)).

So the AsyncUDP packet queue depth is 32 entries.

Was it changed between WLED 0.15.4 and 16.0.0?

The queue size itself was not changed — it has been hard-coded to 32 since AsyncUDP was first added to arduino-esp32 in 2018 and remains 32 today.

However, there was a significant underlying framework change between these two releases for the classic ESP32:

Release	Classic ESP32 framework
WLED v0.15.4	Aircoookie's fork of arduino-esp32 @ 1.0.6.4 (based on ESP-IDF 3.x)
WLED v16.0.0	Tasmota Arduino Core 2.0.18 (based on ESP-IDF 4.4.8)

This is a major ESP-IDF jump (3.x → 4.4.8) for classic ESP32. While the AsyncUDP queue depth is the same, the underlying lwIP stack, FreeRTOS task scheduler, and WiFi driver all changed substantially — any of which could affect the timing behavior you're investigating.

Practical implications

• If the 32-slot AsyncUDP queue fills up (e.g. when the ESP32 is CPU-starved by RMT/WS2812 DMA or WiFi tasks), incoming E1.31 packets will be silently dropped at the lwIP→FreeRTOS handoff, but this behaviour would exist in both versions.
• The new IDF 4.4.8 WiFi driver and lwIP stack may have different interrupt/task priority interactions with the rest of the WLED workload compared to IDF 3.x — this is worth investigating as a root cause.
• Increasing the queue beyond 32 would require patching/rebuilding the arduino-esp32 core, which is not trivial with a pre-built Tasmota platform zip.

[djexplode6]

Can confirm this exact issue, cause and resolution. (Reverting back to 15.3).
I also use esp32 wled for xLights Christmas display using DDP. Should I expect the same lag on units running 16?

[netmindz]

@djexplode6 reverting back isn't a resolution 😉

Can you try the _V4 bin of 0.15 to see if that also has the issue or not please

[djexplode6]

Can you try the _V4 bin of 0.15 to see if that also has the issue or not please

The v4 bin runs fine as well.

[netmindz]

@coderabbitai if the V4 build with 0.15 doesn't hand the issue that would exclude the major IDF version change

[coderabbitai]

@netmindz — that's an excellent deduction and you're right. If the V4 build of 0.15 (which already uses IDF 4.x via Tasmota platform) works without the lag, then the IDF major version jump (3.x → 4.x) is effectively ruled out as the cause.

This narrows the root cause to one (or both) of:

1. WLED application-level code changes introduced between 0.15 and 16.0 — something in how realtime/E1.31/DDP receive, frame processing, or task scheduling was modified.

2. Tasmota platform version drift — from the platformio.ini comparison:

   • WLED v0.15.4 (_V4): platform-espressif32 @ 2022.12.02
   • WLED v16.0.0: platform-espressif32 @ 2025.02.10

   That's ~2 years of ESP-IDF 4.x point releases, sdkconfig changes, lwIP tuning, and WiFi driver updates within the same major IDF version. The IDF version bump within 4.x (e.g. 4.4.x → 5.x or changed sdkconfig defaults) could still be a contributor.

The most actionable next step would be to bisect the WLED application changes between 0.15 and 16.0 related to E1.31/realtime handling, since that's the variable most directly in the WLED team's control.