fix(voice): release the audio pause a finished speech was still holding - #2142
Closed
toubatbrian wants to merge 1 commit into
Closed
fix(voice): release the audio pause a finished speech was still holding#2142toubatbrian wants to merge 1 commit into
toubatbrian wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 05d50d1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 39 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
toubatbrian
force-pushed
the
brian/release-pause-on-speech-done
branch
from
July 28, 2026 02:08
0382f6f to
65620fd
Compare
toubatbrian
changed the base branch from
main
to
brian/clear-sink-before-resume-v2
July 28, 2026 02:08
toubatbrian
changed the title
toubatbrian
changed the title
The paused-speech record taken out when user audio activity pauses a reply was never cleared when that reply finished, so it outlived its owner: the sink stayed gated and a later VAD blip arming the resume timer acted on a speech that was already over. Port Python's _scheduling_task block (agent_activity.py:1630-1637), which drops the record, cancels the false-interruption timer and resumes the output once the generation completes. Co-authored-by: Cursor <cursoragent@cursor.com>
toubatbrian
force-pushed
the
brian/release-pause-on-speech-done
branch
from
July 28, 2026 02:27
65620fd to
05d50d1
Compare
This was referenced Jul 28, 2026
toubatbrian
changed the title
Contributor
Author
|
Closing: this came out of a misdiagnosis on my side. The reported symptom — the agent's audio and its transcript disagreeing after a barge-in, with the lag compounding over a conversation — is caused by the inference gateway answering a single Measured on its own, #2146's branch contains only The defect it fixes is real and has its own red/green test, and the branch is not deleted. If it ever shows up in practice it is worth reproposing on its own merit rather than as a barge-in fix. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Top of a four-PR stack: #2131 → #2132 → #2136 → #2142. Base: #2136 — review only the top commit; the diff against
mainincludes #2131 through #2136.Problem
When user audio activity pauses the agent mid-reply, the activity records which speech the pause belongs to, so the false-interruption timer can resume that same speech if the overlap turns out to be a backchannel. That record is never cleared when the speech itself finishes, so it outlives its owner.
Two consequences, both measured directly on
main: the audio sink stays gated indefinitely after a cleanly finished reply, and the next VAD blip to arm the resume timer acts on a speech that is already over — emitting a spuriousagent_false_interruptionfor a completed reply.Fix
Port the block Python already has. The scheduling loop drops the paused-speech record, cancels the false-interruption timer, and resumes the audio output as soon as the paused speech's generation completes.
Testing
paused_speech_completion.test.tsfails onmain(pausedSpeechstill points at the finished handle) and passes here. Voice suite green at 565 tests.Python parity
This is a missing port, not a design difference. Python has three
audio_output.resume()sites and JS had two; the absent one is_scheduling_taskatagent_activity.py:1630-1637, whose own comment reads "clear paused speech after generation done". The JS loop went straight from awaiting the generation to clearing_currentSpeech. The added block is that Python block, in the same position.Scope — read this before merging
Found while investigating a live report of stale audio replaying after a barge-in. That report has since been traced, and not to this: the inference gateway emits multiple
donemessages persession.flushon some TTS paths, the client returns on the first, and the next reply then reads the previous reply's audio off a socket that was handed back to the pool mid-synthesis. Switching only the TTS provider makes the symptom vanish with no code change. Fixes are in flight separately (#2144, #2146).The reported symptom still reproduces with this whole stack applied. This is a real defect in the pause lifecycle on its own terms, with its own red/green test, and it should be read and merged as that and nothing more.