openclaw / openclaw/openclaw-facetime

FaceTime active-speaker indicator does not pulse for model audio

Open
#7 1 comment 1 reaction 1 assignee View on GitHub

@omarshahine is already working on this.

Since Aug 1, 2026.

bug clawsweeper:needs-maintainer-review clawsweeper:no-new-fix-pr impact:ux-friction issue-rating: 🦪 silver shellfish P2
Dominant language
Objective-C
Stars
0
Forks
1
Avg merge
12h 44m
Merged PRs (30d)
12

Description

Summary

Realtime model speech is audible to the remote FaceTime participant, but FaceTime does not show its green active-speaker pulse around the OpenClaw participant while the assistant speaks.

Call answering, bidirectional audio, barge-in, agent tools, spoken hangup, process-output suppression, and teardown all work on the current paired audio route. This is a UI signaling or voice-activity defect, not an audio-delivery failure.

Current working route

OpenAI Realtime PCM -> OpenClaw-Feed -> paired driver -> OpenClaw-Mic -> FaceTime -> remote caller
  • FaceTime input: OpenClaw-Mic
  • FaceTime output: physical speakers or headphones
  • macOS default input on the dedicated host: OpenClaw-Mic
  • macOS output: physical speakers
  • caller audio is captured and suppressed locally with the native process tap

This route is deployed and stable. Do not replace it or change system speaker output while investigating this issue.

Reproduction

  1. Install and configure the plugin using the paired OpenClaw-Feed / OpenClaw-Mic driver.
  2. Place or answer an allowlisted FaceTime Audio or video call.
  3. Let the realtime assistant speak a clearly audible response.
  4. Observe the remote FaceTime UI.

Expected: FaceTime shows its normal green active-speaker pulse while model audio is transmitted.

Actual: model speech is audible, but the green pulse does not move.

Live evidence

  • Call 47B1D183-4EE3-4FB2-85F7-884C9AB2F385: audible model responses and successful direct spoken hangup; no green pulse.
  • Call 8611E4ED-6B74-4733-8E8B-4D624095955E: stable inbound bidirectional audio after route settling; no green pulse.
  • Call 80D3EB5A-C463-45B3-B98F-89F12D4DF046: answering, realtime speech, and caller-requested hangup worked; no green pulse.
  • On working calls, helper close telemetry reported meter max local=0 remote=0 even while the remote participant heard model speech.

The helper's TUCall.localMeterLevel and remoteMeterLevel values are therefore not a reliable sole oracle for the remote active-speaker UI.

Investigation already completed

  • Adding +3 dB to the SoX output did not restore the indicator. The gain change was removed.
  • Explicitly clearing TUCall's UI mute after barge transmission did not restore the indicator. The helper change was removed.
  • Repository history indicates the pulse worked during the project's earliest tests using the duplex BlackHole 16ch route, before the paired driver was introduced.
  • The first direct BlackHole 16ch comparison was invalid because FaceTime retained its app-specific OpenClaw-Mic preference while only the macOS default changed. The native safety verifier correctly failed closed before provider speech.
  • A second comparison changed FaceTime's actual per-host PreferredAudioInputDeviceUID plus the bridge and verifier to BlackHole 16ch. The call answered and then disconnected before usable model speech, so it produced no green-pulse evidence. The paired production route was immediately restored.

No experimental routing or helper changes remain in the tracked repository or deployed production setup.

Likely boundary

The remaining boundary is between the paired virtual-device topology and FaceTime's outbound voice-activity signaling. Audible PCM reaches the carrier, while FaceTime's private call meters stay at zero.

This is not yet enough evidence to declare the split input/output driver topology the root cause. A future investigation should measure PCM energy directly at the feed and microphone sides and correlate it with FaceTime or AVConference voice-activity state.

Acceptance criteria

  • The receiving FaceTime UI visibly pulses during model speech on the supported paired route.
  • Bidirectional audio, barge-in, spoken hangup, and native process-output suppression remain working.
  • No Mac system-output or app-output changes are required beyond the documented physical-output configuration.
  • Setup does not depend on manually switching the machine between experimental devices.
  • Automated coverage protects any driver, helper, or route-state change where practical.
  • Live proof records the exact head, call mode, audible audio result, visible pulse result, and clean teardown.

Investigation guardrail

Do not modify the dedicated host's proven paired production route for further ad hoc A/B calls. Use an isolated driver identity, offline harness, or another dedicated test environment so a failed experiment cannot break inbound answering or model speech.

Related: #6 landed the call-readiness and safety lifecycle work but intentionally did not claim this indicator was fixed.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.