You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a capture device disappears mid-call (e.g. unplugging a Bluetooth
headset), the local microphone went silent and never recovered:
MicrophoneSource stayed bound to the gone device name and never
re-registered the AudioProbe tap that Unity detaches when it rebuilds
its audio graph.
Subscribe to AudioSettings.OnAudioConfigurationChanged (mirroring the
playback-side AudioStream handler) and restart capture on a device
change, resolving to the OS default device when the preferred device is
no longer present. Track the active device separately from the preferred
one so Microphone.IsRecording/GetPosition/End target the right device,
and guard against overlapping restarts.
The native source's rate is fixed at construction, so if the device
change moves Unity's DSP output rate, frames are still dropped; warn
clearly in that case. Full rate-change recovery follows separately.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Utils.Warning($"MicrophoneSource: audio device change moved the DSP output rate to {outputSampleRate}Hz, but the native source is fixed at {_expectedSampleRate}Hz. Captured frames will be dropped until the track is recreated at the new rate.");
249
+
}
250
+
251
+
// Unity rebuilds its audio graph on any configuration change — including an output
252
+
// route change (e.g. a Bluetooth headset disconnecting) where the input device itself
253
+
// doesn't change. On mobile the input is always the built-in mic regardless of the
254
+
// headset, so deviceWasChanged is false there even though the rebuild detaches the
255
+
// AudioProbe tap and stops capture. Always restart so the tap is re-registered;
256
+
// AudioStream does the same on the playback side and never gates on deviceWasChanged.
0 commit comments