openclaw - ✅(Solved) Fix [Bug]: Google Live browser Talk does not stop queued audio after interruption [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73460Fetched 2026-04-29 06:19:39
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
Timeline (top)
cross-referenced ×2commented ×1

The browser-direct Google Live Talk transport resets its playback cursor when serverContent.interrupted arrives, but it does not stop already scheduled audio sources. Gateway relay tracks and stops queued sources, so browser-direct behavior appears inconsistent and may keep playing stale assistant audio after barge-in.

Root Cause

The browser-direct Google Live Talk transport resets its playback cursor when serverContent.interrupted arrives, but it does not stop already scheduled audio sources. Gateway relay tracks and stops queued sources, so browser-direct behavior appears inconsistent and may keep playing stale assistant audio after barge-in.

Fix Action

Fixed

PR fix notes

PR #73466: fix(ui): stop Google Live browser audio on interruption

Description (problem / solution / changelog)

Summary

  • track browser-direct Google Live audio sources as they are scheduled
  • stop queued output when Google Live sends serverContent.interrupted
  • also clear queued output during transport shutdown

Closes #73460

Test Plan

Adds a regression test for stopping scheduled browser audio sources on Google Live interruption.

  • pnpm exec oxfmt --check --threads=1 ui/src/ui/chat/realtime-talk-google-live.ts
  • pnpm test ui/src/ui/realtime-talk-google-live.test.ts

Changed files

  • ui/src/ui/chat/realtime-talk-google-live.ts (modified, +15/-1)
  • ui/src/ui/realtime-talk-google-live.test.ts (modified, +51/-2)

Code Example

ui/src/ui/chat/realtime-talk-google-live.ts:170-173
- handles serverContent.interrupted by resetting playhead only

ui/src/ui/chat/realtime-talk-google-live.ts:218-223
- creates and starts AudioBufferSourceNode without storing it

ui/src/ui/chat/realtime-talk-gateway-relay.ts:173-190
- relay transport tracks sources and stops them in stopOutput()
RAW_BUFFERClick to expand / collapse

Summary

The browser-direct Google Live Talk transport resets its playback cursor when serverContent.interrupted arrives, but it does not stop already scheduled audio sources. Gateway relay tracks and stops queued sources, so browser-direct behavior appears inconsistent and may keep playing stale assistant audio after barge-in.

Steps to reproduce

NOT_ENOUGH_INFO

Expected behavior

When a Google Live interruption event is received, queued assistant audio should stop immediately and playback state should reset.

Actual behavior

realtime-talk-google-live.ts only resets this.playhead; scheduled AudioBufferSourceNodes are not tracked or stopped.

OpenClaw version

Current main after v2026.4.26; observed at commit 0f24a8d8e1.

Operating system

Static repo inspection only.

Install method

Source checkout.

Model

Google Live realtime model.

Provider / routing chain

Browser Talk -> Google Live browser WebSocket transport.

Logs, screenshots, and evidence

ui/src/ui/chat/realtime-talk-google-live.ts:170-173
- handles serverContent.interrupted by resetting playhead only

ui/src/ui/chat/realtime-talk-google-live.ts:218-223
- creates and starts AudioBufferSourceNode without storing it

ui/src/ui/chat/realtime-talk-gateway-relay.ts:173-190
- relay transport tracks sources and stops them in stopOutput()

Impact and severity

Affected: users of browser-direct Google Live Talk sessions.

Severity: Medium if reproduced.

Frequency: Interruption/barge-in path.

Consequence: stale assistant speech may continue after interruption.

Additional information

A focused test could fake AudioContext / AudioBufferSourceNode, enqueue audio chunks, send { serverContent: { interrupted: true } }, and assert scheduled sources are stopped.

extent analysis

TL;DR

To fix the inconsistent behavior, track and stop scheduled AudioBufferSourceNodes when a Google Live interruption event is received.

Guidance

  • Review realtime-talk-google-live.ts to identify where AudioBufferSourceNodes are created and started without being stored, and consider storing them for later stopping.
  • Implement a mechanism to stop all scheduled AudioBufferSourceNodes when serverContent.interrupted is received, similar to the stopOutput() method in realtime-talk-gateway-relay.ts.
  • Create a test to verify the fix by faking AudioContext and AudioBufferSourceNode, enqueuing audio chunks, sending an interruption event, and asserting that scheduled sources are stopped.
  • Compare the implementation with realtime-talk-gateway-relay.ts to ensure consistency between browser-direct and gateway relay behaviors.

Example

// Example of storing and stopping AudioBufferSourceNode
const audioSources = [];

// When creating an AudioBufferSourceNode
const source = audioContext.createBufferSource();
audioSources.push(source);
source.start();

// When receiving serverContent.interrupted
if (serverContent.interrupted) {
  audioSources.forEach(source => source.stop());
  audioSources.length = 0; // clear the array
}

Notes

The provided code snippet is a simplified example and may need to be adapted to the actual implementation in realtime-talk-google-live.ts.

Recommendation

Apply a workaround by tracking and stopping scheduled AudioBufferSourceNodes when a Google Live interruption event is received, as this will ensure consistent behavior between browser-direct and gateway relay transports.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

When a Google Live interruption event is received, queued assistant audio should stop immediately and playback state should reset.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Google Live browser Talk does not stop queued audio after interruption [1 pull requests, 1 comments, 2 participants]