Restart microphone capture on audio device change

[MaxHeimbrock]

Problem

When a capture device disappears mid-call (e.g. unplugging a Bluetooth headset and falling back to the built-in mic), the local microphone went silent and never recovered:

• MicrophoneSource stayed bound to the now-gone device name and never re-resolved to the new default.
• Unity tears down its audio graph on a device change, which detaches the AudioProbe.OnAudioFilterRead tap — so even the capture tap stopped firing.

The playback side already handles this in AudioStream.OnAudioConfigurationChanged; this mirrors that pattern for capture.

Change

• Subscribe MicrophoneSource to AudioSettings.OnAudioConfigurationChanged and restart capture on a device change (reusing the existing RestartMicrophone coroutine, which re-adds the AudioSource/AudioProbe and re-registers the tap on the rebuilt graph).
• Resolve the capture device to the OS default (null) when the preferred device is gone, so an unplugged headset transparently hands off to the built-in mic.
• Track the active device separately from the preferred one so Microphone.IsRecording/GetPosition/End target the device actually recording.
• Guard against overlapping restarts when the event fires repeatedly around one hardware swap.

The native source's rate is fixed at construction, so if the device change moves Unity's DSP output rate, frames are still dropped; this case is warned about clearly. Full rate-change recovery is a follow-up (stacked PR).

Out Of Scope

Restarts capture on a device change, but the native audio source's rate is fixed at construction. If the new device has a different sample rate, RtcAudioSource silently drops every captured frame (it rejects frames whose rate/channels don't match the source) — so audio stays dead. Full recovery possible with follow up: #312

[MaxHeimbrock]

Triggered on Unity 6 editor on mac starting with MDR-1000x, disabling Bluetooth to switch to built in mic, then connecting to MDR-1000x again:

LiveKit: MicrophoneSource: audio device change moved the DSP output rate to 44100Hz, but the native source is fixed at 48000Hz. Captured frames will be dropped until the track is recreated at the new rate.
UnityEngine.Logger:LogWarning (string,object)
LiveKit.Internal.Utils:Warning (object) (at /Users/maxheimbrock/dev/unity/client-sdk-unity/Runtime/Scripts/Internal/Utils.cs:41)
LiveKit.MicrophoneSource:OnAudioConfigurationChanged (bool) (at /Users/maxheimbrock/dev/unity/client-sdk-unity/Runtime/Scripts/MicrophoneSource.cs:248)
UnityEngine.AudioSettings:InvokeOnAudioConfigurationChanged (bool) (at /Users/bokken/build/output/unity/unity/Modules/Audio/Public/ScriptBindings/Audio.bindings.cs:413)

[MaxHeimbrock]

This worked on https://github.com/livekit/client-sdk-unity/pull/312/changes

[MaxHeimbrock]

New commit adds debug logs to investigate mobile platforms:

Done. The diagnostics are in MicrophoneSource.cs (uncommitted on max/mic-restart-on-device-change), compiling clean. Build and deploy that branch to
  Android, then capture logcat while reproducing.

  Capture logs

  adb logcat -c    # clear
  adb logcat | grep -iE "MicrophoneSource|LiveKit"

  All lines come through under the Unity tag prefixed with LiveKit:.

  Reproduce

  1. Start the call with the BT headset connected, confirm audio reaches the other side.
  2. Watch for the steady-state health line every ~2s: health framesLast2s=<non-zero> isRecording=True position=... muted=False.
  3. Switch Bluetooth off to disconnect the headset, and keep watching.

  What the logs will tell us

  The decisive lines after you switch BT off:

  ┌───────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────┐
  │                              Observation                              │                             Conclusion → fix                             │
  ├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────┤
  │ No OnAudioConfigurationChanged line, and health framesLast2s drops to │ Event never fires on Android; capture stalls silently → frame-flow       │
  │  0                                                                    │ watchdog is the right fix                                                │
  ├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────┤
  │ OnAudioConfigurationChanged … does appear, restart begin/started      │ Event fires and we restart, but the restart doesn't recover on Android → │
  │ successfully/restart end follow, but framesLast2s stays 0             │  deeper issue in StartMicrophone/Microphone.Start                        │
  ├───────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────┤
  │ framesLast2s stays non-zero after BT off, yet the receiver hears      │ Buffers flow but audio is silent/dropped downstream → problem is in the  │
  │ nothing                                                               │ native source path, not capture                                          │
  └───────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────┘

  Paste the chunk of log from a few seconds before the BT toggle to ~10s after, and that picks the fix.

  Two housekeeping notes so nothing gets lost:
  - Your unrelated working-tree edits (scene/ProjectSettings/manifest/.vscode) are still stashed — I'll restore them once we wrap up.
  - #312 is stale (it diverged onto an older base and still has the pre-gate-fix restart commit). I'll rebuild it cleanly as "#311 + republish commit"
  after the Android fix lands, so we don't keep churning it.