ESP32 Forum

Environment:

Chip: ESP32-C5
ESP-IDF: v5.5.4
Mode: SoftAP (single STA connected)
Application: Real-time audio streaming via UDP/RTP (2ms period, 1152 bytes/packet)
Problem:
I'm experiencing periodic sendto() failures with errno=12 (ENOMEM) approximately every 1.5 seconds. Each failure burst consists of 2-3 sub-bursts at ~100ms intervals, with 10-15 consecutive failures per sub-burst.

Log example:

What I've tried (no effect on 100ms pattern):

CONFIG_ESP_PHY_RF_CAL_NONE=y (reduced burst frequency, but 100ms sub-pattern remains)
CONFIG_ESP_PHY_PLL_TRACK_PERIOD_MS=60000
CONFIG_ESP_COEX_SW_COEXIST_ENABLE=n
CONFIG_ESP_WIFI_NVS_ENABLED=n
CONFIG_ESP_WIFI_AMPDU_TX_ENABLED=n / RX_ENABLED=n
CONFIG_ESP_WIFI_DYNAMIC_TX_BUFFER_NUM=128
beacon_interval=1000 (verified via esp_wifi_get_config())
dtim_period=1
Fixed MCS4 rate via esp_wifi_config_80211_tx_rate()
Unicast (not broadcast)

Question:
The 100ms sub-burst pattern persists regardless of configuration changes. Is this caused by an internal WiFi library periodic task (e.g., beacon processing, channel scanning, or other maintenance)?

Is there any way to:

Identify what internal process causes this ~100ms blocking?
Disable or extend the interval of this internal process?
Get notification before WiFi becomes temporarily unavailable?
This is for professional audio equipment requiring <64ms latency. Any guidance would be appreciated.

Sounds like you may be exhausting some buffers of the network stack, e.g. when it can't keep up with your rate of UDP packets. Maybe you're not leaving enough CPU time available to the internal WiFi task.

Thank you very much for your comment.

I also initially suspected CPU starvation or the UDP sending rate,
so I performed several tests to verify that possibility.
However, the behavior I am observing seems a bit different from typical CPU‑load issues.

Here are some additional details that may help:

• The ENOMEM bursts appear with a very stable periodic pattern:
– A major burst every ~1.5 seconds
– Inside it, 2–3 sub‑bursts spaced almost exactly ~100 ms apart
– Each sub‑burst contains around 10–15 consecutive sendto() ENOMEM failures

• This periodic timing does not change even when:
– CPU load is greatly reduced
– Wi‑Fi task priority is increased
– The sending task is pinned to the other core
– AMPDU/AMSDU are disabled
– Beacon interval / DTIM are changed
– MCS is fixed
– SoftAP is disabled and the device is used only as STA with an external router

• Reducing the stream from 4ch → 2ch almost eliminates the bursts,
and increasing back to 4ch makes them reappear immediately.

Because the timing is so regular, it feels like some internal Wi‑Fi MAC/firmware
maintenance process might be temporarily blocking TX buffer allocation
at ~100 ms intervals.

If anyone has information about periodic internal Wi‑Fi behavior in ESP32‑C5
(e.g., buffer GC, TIM/DTIM handling, background housekeeping tasks),
I would really appreciate any hints.

I can also provide a minimal reproducible example and timestamp logs
if that would be helpful for further investigation.

Thank you again for taking the time to reply.