[fix] audio: lock the mic during a meeting so a device switch can't break transcription - #51
Merged
Merged
Conversation
…reak transcription Reported: switching the mic input mid-meeting killed the whole transcription. Root cause: the Settings 'Test mic' (start_mic_test), fired by the device picker or the Test button, opens a SECOND input stream with no guard against an active meeting. On macOS that makes CoreAudio renegotiate the device and silently kills the meeting's capture — audio stops flowing, transcription dies, nothing recovers. The meeting already pins its device at start and holds it; the fix is to stop anything from grabbing the mic mid-meeting: - start_mic_test no-ops while a meeting is recording (reliable backstop). - start_meeting tears down any running test stream so it can't contend. - new meeting_active command; Settings queries it + follows meeting://status to disable the device picker + Test button while recording, with a hint. So once a meeting starts the input device is fixed for its duration — most users are on the system default and nothing should switch it mid-call.
|
❌ The last analysis has failed. |
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reported: switching the mic input mid-meeting killed the whole transcription.
Root cause: the Settings "Test mic" (
start_mic_test) — fired by the device picker or the Test button — opens a second input stream with no guard against an active meeting. On macOS that makes CoreAudio renegotiate the device and silently kills the meeting's capture; audio stops, transcription dies, and the stream's error callback only logs, so nothing recovers.Fix (the meeting already pins its device at start and holds it — just stop anything from grabbing the mic mid-meeting):
start_mic_testno-ops while a meeting is recording (reliable backstop).start_meetingtears down any running test stream so it can't contend.meeting_activecommand; Settings queries it + follows the broadcastmeeting://statusto disable the device picker + Test button while recording, with a hint.So once a meeting starts, the input device is fixed for its duration. tsc + cargo check + tests green.