zephyr-cp: audiobusio.I2SOut.playing never becomes False after a non-looping sample finishes
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- 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
- Ít trao đổi
- Công nghệ
- c
- Lĩnh vực
- embedded-iot
Hướng nghiên cứu
Start in ports/zephyr-cp/common-hal/audiobusio/I2SOut.c, tracing fill_buffer(), the audio thread's exit, and common_hal_audiobusio_i2sout_get_playing(). Then investigate how Zephyr reports that I2S draining has completed and how thread/slab resources are safely released. Done means a non-looping sample finishes draining without its tail being dropped, playing becomes false, and resources can be used safely by a subsequent play().
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Note: This issue was written by Claude (via Claude Code), not by a human. It was filed at the request of @dhalbert while working on the fixes for #10539.
Summary
On the zephyr-cp port, audiobusio.I2SOut has no end-of-playback detection. After a non-looping sample (loop=False) finishes, I2SOut.playing stays True indefinitely — it is only ever cleared by an explicit stop() (or a write error). So the common idiom
i2s.play(sample, loop=False)
while i2s.playing:
pass
hangs forever.
Where
ports/zephyr-cp/common-hal/audiobusio/I2SOut.c
common_hal_audiobusio_i2sout_get_playing()simply returnsself->playing.self->playingis setFalseonly incommon_hal_audiobusio_i2sout_stop()and on ani2s_writeerror.- When a non-looping sample ends,
fill_buffer()setsself->stopping = trueand triggersI2S_TRIGGER_DRAIN; the audio thread then exits — but leavesself->playing == true.
Relationship to #10539
The single-buffer loop=False "no sound" bug (the final GET_BUFFER_DONE buffer being dropped before it was copied) was fixed for zephyr-cp as part of the #10539 work. This playing-never-clears problem is a separate, deeper gap and was deliberately scoped out, because a correct fix is non-trivial in the current design:
- The audio thread cannot clean itself up (it can't
k_thread_join/free from within itself, and settingplaying = falsethere would break the nextplay(), which guards onplaying). - Clearing it from
get_playing()by callingstop()would issueI2S_TRIGGER_DROP, discarding the still-draining tail blocks (theDRAINjust triggered) and cutting off the end of the sample. - Doing it cleanly requires waiting until the I2S peripheral has actually finished draining (a driver-state query the code does not currently perform) before finalizing and freeing resources.
Suggested direction
Add drain-aware completion detection: once the sample is exhausted and the queued blocks have fully drained, clear playing and release the thread/slab resources — without dropping the tail. This likely needs a Zephyr I2S state query and/or coordination with the audio thread's exit.
Notes
- Affects any non-looping sample on zephyr-cp, not just single-buffer
RawSample;WaveFilewithloop=Falsewould exhibit the same stuckplaying. - Other ports (espressif, nordic, raspberrypi, atmel-samd, ...) clear
playingon completion; this gap is specific to zephyr-cp.
- Ngôn ngữ chính
- C
- Star
- 4.6k
- Fork
- 1.4k
- Merge trung bình
- 1 ngày 8 giờ
- Pull request đã merge (30 ngày)
- 155
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của adafruit/circuitpython
-
board breaks api
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
adafruit/circuitpython#11099 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
storage usb zephyr
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
adafruit/circuitpython#11531 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Move silabs to ZephyrĐang mởsilabs
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 20/100
adafruit/circuitpython#11507 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Feature/API request: portable camera capture across ESP-IDF, Zephyr, and parallel interfacesCó thể đã có người làm @tannewt đã nhận hôm nay. Đang mởcircuitpython api displayio enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
adafruit/circuitpython#11505 · 5 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
adafruit/circuitpython#11472 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của adafruit/circuitpython
Issue tương tự
-
[sqlcipher] update to 4.19.0Đang mởcategory:port-update
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
mypaint/libmypaint#209 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[LOGO] Keenetic OSCó thể đã có người làm @Ivan-Alone đã nhận hôm nay. Đang mởlogo request
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
fastfetch-cli/fastfetch#2646 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
rc_runtime_activate_richpresence leaves a half-initialised entry when the buffer allocation failsĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
RetroAchievements/rcheevos#558 ·