Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

zephyr-cp: audiobusio.I2SOut.playing never becomes False after a non-looping sample finishes

Abierto
  • ¿Algo no está bien?
#11,084 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
c
Área
embedded-iot

Línea de trabajo

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().

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

audio bug zephyr

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 returns self->playing.
  • self->playing is set False only in common_hal_audiobusio_i2sout_stop() and on an i2s_write error.
  • When a non-looping sample ends, fill_buffer() sets self->stopping = true and triggers I2S_TRIGGER_DRAIN; the audio thread then exits — but leaves self->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 setting playing = false there would break the next play(), which guards on playing).
  • Clearing it from get_playing() by calling stop() would issue I2S_TRIGGER_DROP, discarding the still-draining tail blocks (the DRAIN just 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; WaveFile with loop=False would exhibit the same stuck playing.
  • Other ports (espressif, nordic, raspberrypi, atmel-samd, ...) clear playing on completion; this gap is specific to zephyr-cp.
Lenguaje dominante
C
Estrellas
4.6k
Forks
1.4k
Merge medio
1 d 8 h
PR fusionados (30 d)
153

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de adafruit/circuitpython

Todos los issues de adafruit/circuitpython

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.