DataStreamAudioReceiver retains registrations after close and shares clear-buffer routing across rooms
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 20/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- audio-video-rtc
Línea de trabajo
Start by reading DataStreamAudioReceiver and Room.register_byte_stream_handler, then trace how clear-buffer RPCs are registered, dispatched, and cleaned up. Check the supplied reproduction and validation records for their stated scope. Done means handlers are safely registered and removed across close, failed start, and separate rooms, and the end marker exposes whether the segment was cleared; the proposed fix is already linked in the issue.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Observed against livekit/agents commit 11c8ad8d74c272cf046e65d83cfe7be46abaec64.
DataStreamAudioReceiver registers a byte-stream handler on its Room, while clear-buffer RPCs are dispatched through a process-wide dictionary keyed only by sender identity. aclose() closes tasks and channels but does not remove either registration.
This produces two lifecycle problems:
- A receiver cannot be closed and recreated on the same Room: the existing lk.audio_stream handler still owns the topic.
- Two different rooms with the same sender identity overwrite the shared clear-buffer dispatch entry. An RPC received in one room can be dispatched to the other room's receiver.
Room.register_byte_stream_handler already rejects a second handler for the same topic. Therefore one receiver per Room is an existing constraint; a process-wide multiplexing table does not enable multiple receivers in one Room.
Proposed fix:
- Register the instance RPC on the receiver's own Room.
- Acquire the exclusive byte-stream registration before registering the RPC.
- Undo that registration if RPC registration fails.
- Unregister both handlers when the owning receiver closes. Closing a second receiver whose start failed must not remove the first receiver's handlers.
A separate public API question arises when handling clear_buffer. The receiver still emits AudioSegmentEnd for a cleared reader, but that event does not expose whether the segment was cleared. Consumers cannot distinguish it from a normally completed segment without reading receiver internals. The attached proposal adds AudioSegmentEnd.interrupted, populated from the receiver's existing cleared flag; it preserves the existing end marker and introduces no new turn state machine.
The registration fix and public end-marker field can be reviewed separately if maintainers prefer. No package version or changelog change is proposed.
Validation results and the standalone real-RTC reproduction are supplied alongside this draft. They must be read with their stated scope; this is not a GPU avatar acceptance report.
Submitted fix and reproducible evidence
Proposed fix: https://github.com/livekit/agents/pull/8289
Standalone reproduction, baseline/proposed results, patch and validation records. The evidence is pinned to a contribution commit and is separate from the source-change PR.
- Lenguaje dominante
- Python
- Estrellas
- 14.6k
- Forks
- 3.9k
- Merge medio
- 2 d 7 h
- PR fusionados (30 d)
- 224
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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de livekit/agents
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
livekit/agents#8284 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
mistralai: expose reasoning_effort on the LLMPosiblemente ocupada @muzman123 la tomó hace 3 días. Abiertoenhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
ci: unit tests pin Python 3.12 while the package advertises 3.14 supportPosiblemente ocupada @huong8373tt-beep la tomó hace 4 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
livekit/agents#8231 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Assistant markup is stripped from chat history when expressive mode is offPosiblemente ocupada @ShivamSharma43 la tomó hace 25 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
livekit/agents#7647 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
docs: openai.LLM vs openai.responses.LLM for HTTP OpenAI-compat hostsQuizá libre de nuevo @AbarnaaSree la tomó hace 65 días y no hay ningún pull request abierto. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
livekit/agents#7022 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de livekit/agents
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Nixtla/mlforecast#823 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
microsoft/ML-For-Beginners#1061 ·
-
bot-found documentation priority: P3
Dificultad 2/5 Menos de una hora Aptitud para principiantes 82/100
madenvel/KalinkaPlayer#503 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
EleutherAI/lm-evaluation-harness#4508 ·
Los mantenedores suelen responder en 1 día