openclaw - 💡(How to fix) Fix Google Meet Chrome talk-back can report speechOutputVerified while participants hear silence via BlackHole/SoX [1 comments, 2 participants]

Summary

Google Meet Chrome agent talk-back can report successful/verified speech output while remote participants hear nothing when using the documented macOS BlackHole 2ch + SoX command-pair path.

In the same live meeting/session, a page-level WebRTC/WebAudio fake microphone proof-of-concept using navigator.mediaDevices.getUserMedia + AudioContext.createMediaStreamDestination() was audible to the remote participant. This suggests the TTS provider and Google Meet itself can send the audio, but the documented BlackHole/SoX command-pair path can produce a false-positive health result on macOS.

This is not the same as the older 8 kHz vs PCM audio quality issue. The plugin reported fresh output bytes and speechOutputVerified: true, but the meeting participant still heard silence.

Environment

• OpenClaw: 2026.5.4 / 2026.5.4-beta.1 generation
• OS: macOS 26.3.1 arm64
• Transport: google_meet transport: "chrome"
• Mode: mode: "agent"
• Google Meet UI locale: Traditional Chinese (zh-TW)
• Audio backend: BlackHole 2ch
• Audio commands: default Google Meet Chrome command-pair path using SoX
• Audio format reported by plugin: pcm16-24khz
• TTS provider used by textToSpeechTelephony: Google TTS fallback after Microsoft telephony was skipped
• Chrome joined as a signed-in Google profile

Private details such as the Meet URL/code and Google account are intentionally omitted.

Related issues / prior art

• #72478 — Google Meet: support reliable headless agent join with audio/transcription health checks
  • Very relevant because it calls out that browser/provider readiness can be confused with real audio participation.
  • The current report is a narrower talk-back false-positive case: test_speech/speech health reported success, but participants heard nothing.
• #72525 — Google Meet Chrome realtime bridge should support higher-fidelity PCM audio
  • Related to the Chrome bridge audio format work.
  • This report is not primarily about fidelity; audio was not audible to participants despite 24 kHz PCM output byte movement.
• #75950 — Google Meet plugin: Linux realtime Chrome join blocked by macOS-only BlackHole audio backend
  • Related because it documents that the realtime Chrome path is currently BlackHole/macOS-specific and alternative backend work is still a gap.
• #73850 — Google Meet realtime voice should allow human barge-in during assistant playback
  • Adjacent because it touches the Google Meet realtime bridge and shared BlackHole loopback/echo suppression behavior.

What happened

The setup and meeting join appeared healthy:

{
  "setup_status": {
    "ok": true,
    "checks": [
      { "id": "audio-bridge", "ok": true, "message": "Chrome command-pair talk-back audio bridge configured (pcm16-24khz)" },
      { "id": "chrome-local-audio-device", "ok": true, "message": "BlackHole 2ch audio device found" },
      { "id": "chrome-local-audio-commands", "ok": true, "message": "Chrome audio command available: sox" }
    ]
  }
}

The Meet tab was in-call and the plugin reported the expected readiness:

{
  "inCall": true,
  "manualActionRequired": false,
  "audioOutputRouted": true,
  "audioOutputDeviceLabel": "BlackHole 2ch (Virtual)",
  "speechReady": true,
  "providerConnected": true,
  "realtimeReady": true,
  "audioInputActive": true,
  "audioOutputActive": true,
  "bridgeClosed": false
}

google_meet test_speech also reported success:

{
  "spoken": true,
  "speechOutputVerified": true,
  "speechOutputTimedOut": false,
  "speechReady": true,
  "audioOutputActive": true,
  "lastOutputBytes": 1038720,
  "lastRealtimeTranscriptRole": "assistant",
  "lastRealtimeTranscriptText": "...test message..."
}

However, the remote participant in the same meeting reported that they heard nothing for multiple attempts.

Additional local audio observations

On the failing host, independent SoX/CoreAudio checks suggested that writing to BlackHole 2ch did not produce a meaningful loopback capture from the same device during the failing setup:

• Generated Google TTS PCM had normal sample levels locally.
• Writing that PCM to CoreAudio BlackHole 2ch using SoX completed without error.
• Capturing from CoreAudio BlackHole 2ch in parallel produced near-silence in this setup, for example RMS around 0.5 and peak 1, across 24 kHz mono and 48 kHz stereo smoke tests.

This may be host/device-configuration-specific, but it is important because OpenClaw still reported speechOutputVerified: true based on bridge output bytes.

Proof-of-concept workaround that was audible

As a live control test, I bypassed the OS-level BlackHole/SoX route and injected a page-level fake microphone into the Meet page before joining:

• Used Chrome DevTools Protocol Page.addScriptToEvaluateOnNewDocument before reloading Meet.
• Patched navigator.mediaDevices.getUserMedia for audio requests.
• Returned a MediaStream from AudioContext.createMediaStreamDestination().
• Played the same Google TTS-generated WAV/PCM into that destination.
• Joined the same meeting with the patched page.
• Played the intro audio through the fake mic track.

The browser-side state looked like:

{
  "patched": true,
  "hasFakeMic": true,
  "trackState": "live",
  "trackEnabled": true,
  "trackLabel": "MediaStreamAudioDestinationNode",
  "ctxState": "running",
  "plays": 1,
  "inCallText": true,
  "micOnText": true
}

The remote participant confirmed they could hear this WebRTC/WebAudio fake mic playback.

This was only a proof-of-concept/workaround, not a proposed final API, but it demonstrates that:

1. TTS generation was not the blocker.
2. Google Meet could transmit the audio to the remote participant.
3. The documented BlackHole/SoX command-pair path or its health verification can fail silently/false-positively on at least one macOS setup.

Expected behavior

At least one of these should be true:

1. speechOutputVerified: true should mean there is strong evidence that audio reached the Meet microphone/sender path, not only that bytes were written to the local output command.
2. If the plugin cannot prove that the Meet mic path is receiving non-silent audio, status should distinguish this clearly, for example:
   • TTS generated bytes
   • bytes written to chrome.audioOutputCommand
   • output command still alive
   • local virtual-device loopback level / RMS
   • Meet sender track active / WebRTC audio level if available
3. The docs/setup should warn that a single shared BlackHole 2ch device may pass setup and byte-output checks while still not being audible in Meet, and should provide a supported validation/remediation path.
4. Consider supporting a browser-level WebRTC/WebAudio microphone source backend for Chrome talk-back, or another supported non-BlackHole route, because the page-level fake mic approach was audible in live testing.

Actual behavior

• The documented BlackHole/SoX command-pair path reported success and fresh output bytes.
• Remote participants heard silence.
• A page-level fake microphone injected into the Meet page was audible.

Why this matters

This creates a dangerous false-positive for meeting assistant use cases: the agent appears joined and the tool reports speech as verified, but humans in the meeting cannot hear it.

For assistants attending live meetings, false success is worse than a clear failure because the operator may assume the agent introduced itself or answered a question when it did not.

Suggested next steps

A maintainer-friendly path could be:

1. Add a regression/diagnostic distinction between "bridge wrote output bytes" and "Meet mic/sender path likely received non-silent audio".
2. Add setup/test-speech diagnostics for macOS BlackHole loopback level or Chrome/WebRTC sender audio level where possible.
3. Document this failure mode next to the existing BlackHole/Loopback guidance.
4. Evaluate an optional Chrome talk-back backend that injects a WebAudio/MediaStream track into Meet instead of relying on OS-level BlackHole output for assistant speech.

Validation performed locally

• google_meet setup_status passed for Chrome agent mode.
• google_meet recover_current_tab confirmed the Meet tab was in-call, mic on, and media output routed to BlackHole 2ch (Virtual).
• google_meet speak returned spoken: true.
• google_meet test_speech returned speechOutputVerified: true and lastOutputBytes > 0.
• Remote participant still heard nothing.
• Page-level fake mic injection + WebAudio playback was audible to the same remote participant.