Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Studio: microphone track is digital silence for the exact duration of a VoIP call, and the recording reports success

Aperta
  • Qualcosa non va?
#2,303 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
macos, rust
Ambito
audio-video-rtc, desktop

Direzione di ricerca

Inizia dalla pipeline di acquisizione del microfono e dalla gestione delle interruzioni audio/keepalive descritte nei log, quindi riproduci il problema su macOS durante una chiamata VoIP. Confronta la traccia del microfono acquisita con il timeout registrato e gli eventi di ripresa. Il lavoro è completato quando la perdita causata dalla chiamata viene evitata oppure rilevata e segnalata chiaramente, invece di essere registrata come una traccia silenziosa acquisita correttamente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

  1. 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.
  2. 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.
  3. 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.

Lingua principale
Rust
Stelle
22.8k
Fork
2k
Merge medio
8h 10m
PR unite (30g)
83

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CapSoftware/Cap

Tutte le issue di CapSoftware/Cap

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.