DataStreamAudioReceiver retains registrations after close and shares clear-buffer routing across rooms
Maintainer thường phản hồi trong vòng 1 ngày
Đá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
- 20/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- audio-video-rtc
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Python
- Star
- 14.6k
- Fork
- 3.9k
- Merge trung bình
- 2 ngày 5 giờ
- Pull request đã merge (30 ngày)
- 232
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 livekit/agents
-
Độ khó 1/5 Dưới một 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
-
mistralai: expose reasoning_effort on the LLMCó thể đã có người làm @muzman123 đã nhận 1 ngày trước. Đang mởenhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ci: unit tests pin Python 3.12 while the package advertises 3.14 supportCó thể đã có người làm @huong8373tt-beep đã nhận 2 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
livekit/agents#8231 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Assistant markup is stripped from chat history when expressive mode is offCó thể đã có người làm @ShivamSharma43 đã nhận 23 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
livekit/agents#7647 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
docs: openai.LLM vs openai.responses.LLM for HTTP OpenAI-compat hostsCó thể làm lại được @AbarnaaSree đã nhận 62 ngày trước và không có pull request nào đang mở. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
livekit/agents#7022 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của livekit/agents
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Claiming namespace `thejakia1`Đang mởnamespace operations
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
EclipseFdn/open-vsx.org#15057 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Mission statement: why this is free, in the README, Why This Exists and the wiki HomeCó thể đã có người làm @ChiefGyk3D đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
ChiefGyk3D/Clouds-Against-Humanity#348 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Perf] Default --vllm-watermark 0.05 for rollouts (hybrid models re-preempt under KV pressure)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
vllm-project/vime#508 ·
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ 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 1 ngày