fix(macos): resolve Chromium USB microphone labels - #648
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe change adds shared microphone device resolution, uses it during ScreenCaptureKit recording, adds XCTest coverage, and records partial macOS manual validation for explicit microphone selection. ChangesMicrophone resolution
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Sequence Diagram(s)sequenceDiagram
participant ScreenCaptureRecorder
participant AVCaptureDevice
participant resolveMicrophoneDeviceID
ScreenCaptureRecorder->>AVCaptureDevice: list audio devices
AVCaptureDevice-->>ScreenCaptureRecorder: uniqueID and localizedName
ScreenCaptureRecorder->>resolveMicrophoneDeviceID: microphone ID, name, mapped devices
resolveMicrophoneDeviceID-->>ScreenCaptureRecorder: resolved microphone ID or nil
Merge Risk: ⚪ Minimal · up to The explicit USB microphone selection path has no identified merge-blocking issue. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 12.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 8 functions across 3 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Selecting a USB microphone in the macOS HUD can fail to select that microphone for native recording: Chromium reports
Shure MV7 (14ed:1012), while AVFoundation reportsShure MV7. The renderer forwards the decorated label and a Chromium device ID, so neither the existing exact-name lookup nor the native-ID lookup resolves it. Device preview can work while native capture falls back to the system default.Resolve a valid native ID first, then an exact name, then a unique name after removing only a trailing USB VID:PID suffix. Preserve exact decorated names, reject ambiguous name matches, and leave the existing unresolved-device warning/default behavior intact. Add six Swift regression tests in the capture core.
Related issue
Reported during local use of v1.11.0 on macOS 26.6.2 with a Shure MV7. Changing the system default input to MV7 restored recording. No existing issue is being closed. This PR addresses device selection; it does not claim to fix all causes of silent system audio.
Type of change
Release impact
Desktop impact
Screenshots / video
No visual changes. Local desktop recordings are not attached because they contain private workspace content.
Testing
swift test --package-path electron/native/screencapturekit: 31 passed, including 6 new resolver tests.swift build -c release --package-path electron/native/screencapturekit: passed for both helpers.npm run test: 226 files passed; 2,764 tests passed, 1 skipped. An initial run while Electron was unavailable failed to load 8 suites; after installing the official Electron 41.2.1 runtime, the full rerun passed.npx tsc --noEmitandnpx tsc -p tsconfig.test.json --noEmit: passed.npm run lint:fix: no errors or edits; existing warnings remain.npm run docs:checkandgit diff --check: passed.Limits: system default was also MV7 during the smoke test, so the audio test alone does not demonstrate non-default routing; the direct resolver check covers identity. Listening, non-default-input recording, combined/system audio, export and other platforms were not tested. Local JS checks used Node 24.14.0/npm 11.9.0; upstream CI uses the pinned runtime. Installed official app was not modified.
Summary by CodeRabbit
Bug Fixes
Documentation