Summary
On macOS, if a VoIP call is active, a Studio recording's audio-input.m4a contains
silence for precisely the span of that call. The screen and system-audio tracks are
perfect. Cap's own log reports a healthy microphone pipeline from start to finish and
the recording completes normally, so nothing indicates the microphone was lost —
not the UI, not the log, not the file's duration or waveform length.
Two real recordings were lost this way before the cause was found by ear.
This appears to be the macOS defect Rogue Amoeba documents as "Lost Call Audio"
("audio could be lost in FaceTime, Facebook Messenger, WhatsApp, or the new Phone app").
They worked around it with an alternate capture method. The request here is that Cap
either route around it too, or — at minimum — detect it and say so.
Environment
- Cap 0.6.0, Studio mode, system audio on
- macOS 26.5.2 (Darwin 25.5.0), Apple Silicon
- Microphone: MacBook Pro Microphone (built-in). No Bluetooth involved — the
headset was disconnected and the built-in mic was the system default input
- Input volume: 100
What happens
Recording B, 215 s, with a 3.5-minute call starting partway through. Non-zero sample
fraction and RMS per 5 s window of audio-input.m4a:
13:11:47 0s 3.99% non-zero -91.5 dBFS Cap started; call NOT yet connected
13:11:57 10s 5.16% non-zero -92.7 dBFS
13:12:02 15s 0.00% non-zero -240.0 dBFS <-- call connects. EXACT digital zero
... 190 seconds of exact zero ...
13:15:07 200s 0.00% non-zero -240.0 dBFS
13:15:12 205s 4.89% non-zero -90.8 dBFS <-- call ends. device returns
13:15:17 210s 4.13% non-zero -90.6 dBFS
The transition is not gradual and not a coincidence of timing: the zeros begin at
13:12:02 and end at 13:15:13, which match the call's own start and end to the second.
Recording A, 2252.885 s, entirely inside a call: 36,046,165 samples, 2,768 of them
non-zero — 0.008%, mean −91.0 dBFS.
A quiet room is not this. Quiet audio has a continuous noise floor; these are
exact zeros. The distinction matters because a level alone looks merely "quiet":
−91 dBFS and −56 dBFS both read as quiet and only one of them is a loss.
Cap reports success throughout
Microphone source configured device=MacBook Pro Microphone source_rate=44100
source_channels=1 source_format=F32(Packed) target_rate=48000
Start gate admitted first audio frame at the arm point held_frames=16 trimmed_samples=190
Microphone data timeout, awaiting delivery before keepalive silence is_wireless=false
Microphone data resumed after silence stall_ms=273 reconnect_attempts=0
Audio gap tracking summary silence_insertions=1 total_silence_ms=199
Task finished successfully
Cap notices a 273 ms stall at the moment the call connects, treats it as a transient,
inserts keepalive silence and carries on — for the next three minutes of zeros. In
recording A the same pattern produced one logged 199 ms gap across 37.5 minutes that
were entirely silent.
It is not the device, the permission, the format, or exclusivity
Each eliminated by measurement on the same machine, same device, same Cap build:
| hypothesis |
measurement |
result |
| Cap lacks mic permission |
control recording via cap record start, no call: 99.404% non-zero, −46.2 dBFS |
works |
| device broken / muted |
fresh capture after the call ended: 97.18% non-zero, −19.7 dBFS; input volume 100 |
works |
| sample-rate mismatch |
device native format read directly: 44100 Hz mono f32 — exactly what Cap logged |
matches |
| mic can't have two clients |
a second recorder capturing the same device over the same window got 479 and 36 transcribed segments |
works |
| Cap opened the device too late |
in recording B Cap was started before the call connected and still lost it |
not ordering |
That fourth row is the useful one: another process recording the built-in microphone
concurrently, through a different capture path, kept receiving real audio for the whole
call while Cap received zeros. So the audio is still obtainable during a call — Cap's
capture path specifically is the one that gets starved.
Requests
- Do not report success on an all-zero microphone track. A cheap end-of-recording
check — non-zero sample fraction over the mic track — would have caught both of these
at the moment they happened instead of days later. A warning in the UI, or a flag in
recording-meta.json, would be enough.
- Treat a sustained keepalive-silence run as an error condition, not a transient.
The log already knows: "Microphone data timeout" fired at the exact second the loss
began. Right now that becomes an INFO "resumed" line and the loss continues silently.
- Consider the alternate capture path that Rogue Amoeba adopted for this same macOS
defect, given a concurrent recorder demonstrably keeps working during the call.
Happy to supply the full logs, the per-window measurements, or to test a build.
Summary
On macOS, if a VoIP call is active, a Studio recording's
audio-input.m4acontainssilence for precisely the span of that call. The screen and system-audio tracks are
perfect. Cap's own log reports a healthy microphone pipeline from start to finish and
the recording completes normally, so nothing indicates the microphone was lost —
not the UI, not the log, not the file's duration or waveform length.
Two real recordings were lost this way before the cause was found by ear.
This appears to be the macOS defect Rogue Amoeba documents as "Lost Call Audio"
("audio could be lost in FaceTime, Facebook Messenger, WhatsApp, or the new Phone app").
They worked around it with an alternate capture method. The request here is that Cap
either route around it too, or — at minimum — detect it and say so.
Environment
headset was disconnected and the built-in mic was the system default input
What happens
Recording B, 215 s, with a 3.5-minute call starting partway through. Non-zero sample
fraction and RMS per 5 s window of
audio-input.m4a:The transition is not gradual and not a coincidence of timing: the zeros begin at
13:12:02 and end at 13:15:13, which match the call's own start and end to the second.
Recording A, 2252.885 s, entirely inside a call: 36,046,165 samples, 2,768 of them
non-zero — 0.008%, mean −91.0 dBFS.
A quiet room is not this. Quiet audio has a continuous noise floor; these are
exact zeros. The distinction matters because a level alone looks merely "quiet":
−91 dBFS and −56 dBFS both read as quiet and only one of them is a loss.
Cap reports success throughout
Cap notices a 273 ms stall at the moment the call connects, treats it as a transient,
inserts keepalive silence and carries on — for the next three minutes of zeros. In
recording A the same pattern produced one logged 199 ms gap across 37.5 minutes that
were entirely silent.
It is not the device, the permission, the format, or exclusivity
Each eliminated by measurement on the same machine, same device, same Cap build:
cap record start, no call: 99.404% non-zero, −46.2 dBFSThat fourth row is the useful one: another process recording the built-in microphone
concurrently, through a different capture path, kept receiving real audio for the whole
call while Cap received zeros. So the audio is still obtainable during a call — Cap's
capture path specifically is the one that gets starved.
Requests
check — non-zero sample fraction over the mic track — would have caught both of these
at the moment they happened instead of days later. A warning in the UI, or a flag in
recording-meta.json, would be enough.The log already knows: "Microphone data timeout" fired at the exact second the loss
began. Right now that becomes an INFO "resumed" line and the loss continues silently.
defect, given a concurrent recorder demonstrably keeps working during the call.
Happy to supply the full logs, the per-window measurements, or to test a build.