openclaw / openclaw/openclaw-facetime
FaceTime active-speaker indicator does not pulse for model audio
@omarshahine is already working on this.
Since Aug 1, 2026.
- 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
- Install and configure the plugin using the paired
OpenClaw-Feed/OpenClaw-Micdriver. - Place or answer an allowlisted FaceTime Audio or video call.
- Let the realtime assistant speak a clearly audible response.
- 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=0even 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 16chroute, before the paired driver was introduced. - The first direct
BlackHole 16chcomparison was invalid because FaceTime retained its app-specificOpenClaw-Micpreference 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
PreferredAudioInputDeviceUIDplus the bridge and verifier toBlackHole 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.