Summary

Google Meet realtime sessions can resume stale assistant audio after Gemini Live reports an interruption. The provider already emits onClearAudio when serverContent.interrupted is true, and the shared realtime runtime forwards that to audioSink.clearAudio, but the Google Meet Chrome command-pair sinks do not implement clearAudio.

Why this matters

Google's Live API docs say an interrupted server content event is the signal to stop playback and empty the current client-side audio queue. Without a sink-level clear, SoX/Chrome output can continue buffered audio later, which makes the assistant sound like it resumes an old sentence after the user speaks again.

References:

• Gemini Live API reference: server_content.interrupted indicates client interruption; realtime input supports activity_handling and turn_coverage.
• Gemini Live best practices: discard the client-side audio buffer immediately on interruption.
• OpenClaw Google Meet docs: the Chrome command-pair path pipes 8 kHz G.711 mu-law audio between commands and the realtime provider.

Proposed fix

• Expose Google realtime provider config for activityHandling, turnCoverage, and optional disabled automatic activity detection.
• Implement clearAudio in Google Meet Chrome command-pair and chrome-node paths.
• Restart the output command on clear so buffered SoX/Chrome playback cannot resume old audio.
• Surface lastClearAt and clearCount in health/status data for diagnostics.

Separate follow-up

The current Google Meet command-pair path is documented as 8 kHz G.711 mu-law, which is likely why assistant audio sounds telephone-band. A separate higher-fidelity bridge format would be needed for HD audio.