macOS: microphone recorded as silence (native ScreenCaptureKit capture, 1.11.0) #709

Summary

On macOS, a recording made with the microphone enabled has a silent audio track. The screen video is fine, and the microphone works elsewhere in the app.

Reported by a user (private message, 2026-09-18):

• MacBook Pro M1, macOS Tahoe 26.6.2 (25G83)
• OpenScreen 1.11.0 (DMG)
• Tried both the built-in microphone and an external one. Both are listed in the HUD device settings, and the level meter moves there.
• Every take opens in the editor with blank audio.
• Recording a voice-over in the editor afterwards works, and so does transcribing it. So the microphone, its permission and STT are all fine. Only the native capture path is affected.

What was ruled out

• Signing / entitlements: the published Openscreen-Mac-arm64-1.11.0.zip is notarized. Both the app and openscreen-screencapturekit-helper carry com.apple.security.device.audio-input under the hardened runtime, and NSMicrophoneUsageDescription is present.
• Permission: the helper throws permissionDenied when access is not authorized, so a missing grant would fail the take outright rather than record silence.

Probable cause

AudioTrackMixer (electron/native/screencapturekit/Sources/OpenScreenCaptureCore) places every source buffer on the timeline by its raw presentation timestamp. That assumes the microphone output is stamped on the host clock the writer session runs on. ScreenCaptureKit does not promise this: according to Apple, the microphone and app audio are on independent clocks (forum thread 805892).

If the microphone's time base is off by more than a moment, all of its audio lands either before frame 0, where it is trimmed as pre-roll, or after the end of the take, where it is never reached. The result is a silent track with no error surfaced.

Why we never saw it: the only macOS test machine has no input device at all. There, ScreenCaptureKit's microphone output mirrors system audio, clock included, so the assumption held every time we tested.

Not yet confirmed on real hardware. The diagnostics export (helperOutput.mac) carries the audio-timeline-summary line. With the fix it also reports microphone.clockOffsetSeconds, which confirms or refutes this in one take.

Fix

The first buffer of each source decides whether its clock is foreign:

• Within 1 s of the capture clock, nothing changes. That gap is ordinary latency.
• Beyond 1 s, the source is realigned once so that first buffer ends at arrival. Later buffers keep their own spacing.

The offset is reported in the timeline summary, and an audio-source-clock-rebased warning is emitted once.