Task watchdog on ESP32 after a long receive stall: sync task starves the main loop while catching up

Đang mở
  • Có gì không ổn?
#223 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Boisti13 đang làm issue này rồi.

Từ ngày 3/11/2026.

  • #224 của @Boisti13 — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
cpp
Lĩnh vực
audio-video-rtc, embedded-iot

Hướng nghiên cứu

Start with src/sync_task.cpp around SyncTask::process_playback_progress() and the inner loop in SyncTask::thread_entry(), then inspect src/platform/shadow_slot.h and decode_chunk()'s load-time skip behavior. Reproduce a long receive stall with ESP32 watchdog logging and determine whether backlog processing prevents lower-priority tasks from running. Done means a change prevents watchdog resets while preserving correct playback; linked PR #224 is already open.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

An ESP32 Sendspin player (ESPHome) gets restarted by the task watchdog on core 1 shortly after a long receive stall. The crashed task is SsSync. It looks like the sync task works through the backlog that arrives after the stall without blocking, and at its priority (6, above ESPHome's loopTask at 1) it starves the main loop past the 5 s task-watchdog timeout.

Setup

  • AI-Thinker ESP32-A1S audio kit (ESP32-WROVER, 8 MB PSRAM, ES8388), CPU at 240 MHz
  • ESPHome 2026.10.1, sendspin-cpp 0.9.3 (pulled in by ESPHome)
  • sendspin: task_stack_in_psram: false, media_source: - platform: sendspin, buffer_size: 2500000
  • I2S speaker, 48 kHz, buffer_duration: 100ms
  • Server: Music Assistant 2.10.8; Wi-Fi around -50 to -65 dBm, but the player regularly gets no data for 4–15 s

What happened (2026-11-03, local time)

  • 13:00:35 Music Assistant (aiosendspin) logs Slow send_bytes: 11581.6ms ... role=player
  • ~13:01:05 the player restarts: reset reason task watchdog
  • 13:01:10 server logs WebSocket closed, close_code=1006; the player is back at 13:01:14

Crash record:

Reason: Task wdt
Crashed core: 1
PC: 0x400D7EDA
BT: 0x400D7ED7 0x400D840D 0x400E6FBD 0x400F8A21 0x400F92A7 0x401BEB8B 0x401B0501 0x400D82B4

Decoded with the ELF of that exact build:

pthread_mutex_lock_internal            pthread.c:716
pthread_mutex_lock                     pthread.c:746
std::mutex::lock()                     std_mutex.h:113
sendspin::ShadowSlot<sendspin::PlaybackProgress>::take(...)   src/platform/shadow_slot.h:54
sendspin::SyncTask::process_playback_progress(...)            src/sync_task.cpp:879
sendspin::SyncTask::thread_entry(void*)                       src/sync_task.cpp:1035
std::thread ... execute_native_thread_routine / pthread_task_func

What I think is going on (not verified)

The program counter sits in the playback-progress mutex, which is most likely just where SsSync happened to be when the watchdog fired, not a deadlock: process_playback_progress() runs on every pass of the inner loop. The inner loop only blocks in take_item() (15 ms) when the inbound ring is empty, and in the sink write. After a long stall the ring refills quickly, so LOAD_CHUNK → (skip or decode) → SYNCHRONIZE_AUDIO → LOAD_CHUNK can run back to back. decode_chunk() does skip chunks that are late against new_audio_client_playtime before decoding them, but per #198 that estimate is stale after the sink starves, so after the stall the backlog may still be decoded (and then dropped or played late) rather than skipped. At priority 6 on the main loop's core, a few seconds of that is enough for the 5 s task watchdog. I haven't confirmed which branch the task was looping in.

An earlier variant on the same device (v0.7.0 of my firmware, stacks in PSRAM, 160 MHz) crashed the same way but with the PC in the protocol task's decryption during buffer refills; moving stacks to internal RAM and going to 240 MHz made that one go away.

https://github.com/esphome/esphome/issues/18789 looks like the same pattern on the same board (FLAC decode inside the sync task, task wdt, after Lost sync warnings on weak Wi-Fi).

#198 (in 0.9.4+) changes how the hard sync is measured after the sink starves; I have not tested whether it avoids the long late-drop run.

Possible fixes

  • Block briefly (e.g. vTaskDelay(1); std::this_thread::yield() doesn't help lower-priority tasks) after N inner-loop passes that didn't block, so the main loop gets CPU while a backlog is worked off.
  • Check whether #198's floored estimate also lets the load-time skip in decode_chunk() discard the post-stall backlog without decoding it (the PR deliberately keeps the unfloored estimate there).
  • Make the sync task priority configurable from ESPHome, or run it below the main loop when the core is shared.

Happy to test a build. This report was put together with the help of an AI assistant (Claude); the logs and backtrace are from the device.

Ngôn ngữ chính
C++
Star
32
Fork
19
Merge trung bình
14 giờ 54 phút
Pull request đã merge (30 ngày)
49

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Sendspin/sendspin-cpp

Tất cả issue của Sendspin/sendspin-cpp

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.