Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,303 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@ManthanNimodiya đang làm issue này rồi.

Từ ngày 18/9/2026.

  • #2313 của @ManthanNimodiya — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
macos, rust
Lĩnh vực
audio-video-rtc, desktop

Hướng nghiên cứu

Bắt đầu với pipeline thu âm microphone và việc xử lý khoảng trống âm thanh/keepalive được mô tả trong các log, sau đó tái hiện vấn đề trên macOS trong một cuộc gọi VoIP. So sánh track microphone đã thu với timeout được ghi log và các sự kiện tiếp tục. Được xem là hoàn tất khi sự mất tín hiệu do cuộc gọi gây ra либо được tránh, либо được phát hiện và báo cáo rõ ràng, thay vì được ghi lại dưới dạng một track im lặng thành công.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
23k
Fork
2k
Merge trung bình
19 giờ 50 phút
Pull request đã merge (30 ngày)
72

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CapSoftware/Cap

Tất cả issue của CapSoftware/Cap

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.