DataStreamAudioReceiver retains registrations after close and shares clear-buffer routing across rooms

オープン
  • 何か問題がありますか？
#8,288 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@Zheng-Changfu がすでに取り組んでいます。

2026年10月30日 から。

  • #8289 @Zheng-Changfu による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
20/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
python
領域
audio-video-rtc

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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:

  1. A receiver cannot be closed and recreated on the same Room: the existing lk.audio_stream handler still owns the topic.
  2. 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.

主要言語
Python
スター
14.6k
フォーク
3.9k
平均マージ
2日 20時間
マージ済み PR（30日）
248

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

livekit/agents のほかの issue

livekit/agents の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。