Recover microphone capture when the device disappears mid-call#309
Closed
MaxHeimbrock wants to merge 4 commits into
Closed
Recover microphone capture when the device disappears mid-call#309MaxHeimbrock wants to merge 4 commits into
MaxHeimbrock wants to merge 4 commits into
Conversation
MaxHeimbrock
force-pushed
the
max/mic-switch-device
branch
from
0283b9c to
77cb74e
Compare
MaxHeimbrock
changed the title
MaxHeimbrock
force-pushed
the
max/mic-switch-device
branch
from
77cb74e to
d7c35bd
Compare
When the active capture device vanishes (e.g. a Bluetooth headset disconnects), Unity's Microphone clip silently stops filling and capture went permanently dead. Detect and recover automatically: - Detection: the clip's position counter advances continuously while a device is alive (even in silence), so CaptureLoop treats a counter that hasn't moved for 1s - or IsRecording dropping to false - as device loss. - Recovery: end the dead device and retry until a device is available, preferring the original device if it reappears and falling back to the system default microphone otherwise. The normal start path re-measures the new device's rate and fragmentation, so recovering onto or off a misbehaving device (macOS Bluetooth HFP) works transparently. The published track is unaffected throughout: the native source's format is fixed (48kHz mono) and captured audio is resampled to it, so there is no republish or renegotiation - only a capture gap until a device is acquired. Also adds MicrophoneSource.SwitchDevice(deviceName) as the manual counterpart (same mechanism, app-initiated) and a DeviceName getter. Each CaptureLoop carries a generation token and is retired when a newer capture (restart, switch, or recovery) supersedes it, so rapid transitions cannot leave two loops reading different clips; recovery pauses while the app is backgrounded so it cannot fight the iOS pause/resume handling. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
MaxHeimbrock
force-pushed
the
max/mic-switch-device
branch
from
d7c35bd to
d8d5383
Compare
…iceCaps) The previous attempt also dropped Microphone.GetDeviceCaps and requested the target rate (48kHz) directly, on the assumption it was only a hint. It is not: requesting 48kHz makes Unity open the Bluetooth HFP mic in a different mode (clip 48kHz/96000, fragments ~901 of 2880) whose geometry our reconstruction doesn't handle, breaking the audio. The caps-clamped request (16kHz) opens the device in its native mode with the verified-good 320-of-1024 fragmentation. Restore GetDeviceCaps and keep only the safe part of the noise reduction: RecoverRoutine now waits (polling Microphone.devices, which doesn't initialize a device) for the lost device to leave the list before calling back into the audio subsystem. That defers GetDeviceCaps/Start until after the teardown has settled, cutting the FMOD "Failed to get recording driver capabilities" lines without changing what rate is requested - so capture behavior is unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
MaxHeimbrock
force-pushed
the
max/mic-switch-device
branch
from
73e00fb to
46481e9
Compare
When the active mic disappears mid-call (e.g. a Bluetooth headset powers off), RecoverRoutine waited only for the lost device to leave the list, then immediately started the fallback. The OS hadn't yet made the replacement default's recording driver startable, so the first Microphone.Start tripped FMOD error 80 (FMOD_ERR_UNSUPPORTED) and returned null — spamming the console even though the 1s retry loop eventually recovered. - Add a short settle delay before recovery's first start attempt so the new driver is ready; the first attempt now usually succeeds, so even FMOD's own native (80) log line stops firing. - Downgrade transient start failures to debug level during recovery (quietFailure), since they are expected and retried. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The native source rate lived in two places: MicrophoneSource.TargetSampleRate mirrored RtcAudioSource.DefaultSampleRate. RtcAudioSource already stores the configured rate, so expose it and make it the single source of truth. - RtcAudioSource: add protected ExpectedSampleRate/ExpectedChannels. - MicrophoneSource: drop the TargetSampleRate const; construct the native source with the shared DefaultSampleRate (48kHz on all platforms, so behavior is unchanged) and read ExpectedSampleRate everywhere else. The resample target is now tied to what the native source was configured with. - Cache the WaitForSeconds yield instructions instead of allocating per yield. - Extract a shared PollUntil(condition, timeout) coroutine for the two duplicated poll-with-timeout loops (RecoverRoutine's removal loop keeps its extra guard conditions and is left as-is). Pure refactor; no functional change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Stacked on #308. Makes the SDK survive the active microphone disappearing mid-call — e.g. a Bluetooth headset disconnecting — instead of going permanently silent.
Behavior
CaptureLoop): the mic clip's position counter advances continuously while a device is alive — even in silence — so a counter that hasn't moved for 1 s, orMicrophone.IsRecordinggoing false, means the device is gone. No false positives from a quiet room.Also included, since it is the same mechanism app-initiated: an internal
MicrophoneSource.SwitchDevice(deviceName)(the manual primitive, kept non-public until a device-picker API is designed) and a publicDeviceNamegetter.Robustness
CaptureLoopcarries a generation token and retires itself when a newer capture (restart, switch, or recovery) supersedes it — rapid transitions can't leave two loops reading different clips.Verification
🤖 Generated with Claude Code