DuplexRealtimeAdapter: transcript fragment for audio that is never sent anchors the next burst, shifting transcripts by one utterance
维护者通常 1 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- python
调研方向
Start with the repro test test_words_for_sound_never_sent_do_not_anchor_the_next_burst in tests/test_duplex_adapter.py and run it with -k never_sent to see the stale fragment become the next utterance. Read how DuplexRealtimeAdapter queues transcript fragments and decides their fate in _close_burst, _on_transcript_delta, and the 3 s unclaimed rule. Done means the test passes and fragments for audio that was never sent are neither used as words nor as an anchor.
由索引模型根据 Issue 内容生成。
描述
Bug Description
After a barge-in, DuplexRealtimeAdapter can put the model's cut-off words on its next utterance, and every later transcript then lands one utterance late.
- The model's transcript runs ahead of its audio. The user barges in, the model yields, and the audio for its last stamped fragment is never sent.
- That fragment is neither due (
_close_burst) nor late (_on_transcript_delta), so it stays queued. The 3 s unclaimed rule runs on the audio clock, which stops while the provider sends nothing ("it may stop between bursts"). A provider that streams its silence instead is caught by the rule only if the model stays quiet for 3 s. - The next burst takes the stale fragment as its first words and its anchor. Its own words are then held against the wrong anchor and roll into the burst after it, and the last utterance's words can be lost.
#7264 fixed this for audio that was played. This is the case where the audio is never played. It is still present on main (the adapter is unchanged since 1.8.7).
Expected Behavior
Words for audio that was never sent never become the next utterance's words or set its anchor. Nobody heard them, so they should not be captioned or recorded either, the same as the played-text-only rule for interrupted realtime messages.
Reproduction Steps
Add the test below to tests/test_duplex_adapter.py and run uv run pytest tests/test_duplex_adapter.py -k never_sent. On main it fails with assert ' there.' == 'Next.': the cut-off " there." became the second utterance's text and "Next." is still queued.
test
async def test_words_for_sound_never_sent_do_not_anchor_the_next_burst(duplex) -> None:
fake, session, generations = duplex
fake.push(0.001, count=20, start_ms=0)
fake.push(0.3, count=3, start_ms=2000)
await _settle()
fake.say("Hello", start_ms=2000, end_ms=2200)
fake.say(" there.", start_ms=3500, end_ms=3800) # its sound never comes
fake.push(0.001, count=8, start_ms=2300)
await _settle()
fake.say("Next.", start_ms=6000, end_ms=6200) # nothing was sent in between
fake.push(0.3, count=3, start_ms=6000)
fake.push(0.001, count=8, start_ms=6300)
await _settle()
assert len(generations) == 2
assert (await asyncio.wait_for(_read(generations[1]), timeout=1))[1] == "Next."
assert not session._fragments
Operating System
Any (in-process unit test)
Models Used
A custom DuplexModel for a self-hosted MiniCPM-o 4.5. The repro uses the suite's fake DuplexModel.
Package Versions
livekit-agents==1.8.7 (also main @ 334d336)
Session/Room/Call IDs
n/a
Proposed Solution
#7862, for providers that stamp their audio.
Additional Context
We found this by reading the adapter while deciding whether our plugin should stamp its output. Our live plugin sends unstamped fragments and does not hit it.
Screenshots and Recordings
n/a
- 主要语言
- Python
- 星标
- 14.6k
- 派生
- 3.9k
- 平均合并
- 3 天 1 小时
- 30 天内合并 PR
- 166
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
livekit/agents 的其他 Issue
-
Agent state stays "speaking" after a realtime reply in sessions without audio output可能已有人在做 @Luke-salinero 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
Assistant markup is stripped from chat history when expressive mode is off可能已有人在做 @ShivamSharma43 于 9 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
docs: openai.LLM vs openai.responses.LLM for HTTP OpenAI-compat hosts可能重新可做 @AbarnaaSree 于 49 天前认领,目前没有进行中的 PR。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
Google LLM plugin leaves Gemini thinking tokens out of completion_tokens可能已有人在做 @ninglinLiu 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 38/100
维护者通常 1 天内回复
-
OpenAI realtime: a text user turn queued during a tool-output push deletes the function_call_output from the server conversation可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 45/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 64/100
aws-samples/sample-per-model-bedrock#295 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 76/100
pyrevitlabs/pyRevit#3792 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 69/100
zephyrproject-rtos/reqmgmt#177 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
polarsource/polar#15580 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 85/100
521xueweihan/HelloGitHub#4011 ·