Capture microphone by polling the clip directly (no AudioSource/OnAudioFilterRead)

[MaxHeimbrock]

Problem

MicrophoneSource captured the mic by playing its looping AudioClip through an AudioSource and tapping the DSP output in AudioProbe.OnAudioFilterRead. That path has two unsynchronized clocks — the mic hardware clock (fills the clip) and the audio-output/DSP clock (plays it back). With no sync between the write cursor and the playback read cursor, they drift, and when they cross you get periodic gaps = choppy audio. It also resampled the mic to the output rate and ran the capture/encode work on the real-time audio thread.

Change

Read the mic clip's ring buffer directly instead of playing it:

• A main-thread coroutine polls each frame: it reads the new samples between the last read position and Microphone.GetPosition (splitting at the ring-buffer wrap so each AudioClip.GetData read is contiguous), downmixes to mono if needed, and pushes to the native source. No AudioSource, no AudioProbe, no playback cursor → no drift.
• Capture runs on the main thread (Unity audio APIs + FFI are main-thread-friendly); the native source's internal queue absorbs the per-frame pacing jitter and re-paces to 10 ms frames for WebRTC.
• The capture rate is resolved before start from Microphone.GetDeviceCaps (DefaultMicrophoneSampleRate clamped into the device's supported range), and the native source is created at that rate / mono via a new explicit-format RtcAudioSource(type, sampleRate, channels) constructor — so pushed frames always match the native source and never trip a rate/channel mismatch. We don't assume the requested rate is honored: we read clip.frequency and, if it differs (e.g. the device changed since construction), skip capture with a warning instead of resampling.

RtcAudioSource's existing (int channels, RtcAudioSourceType) constructor now delegates to the new explicit-format one; no behavior change for other sources. The MicrophoneSource(deviceName, sourceObject) signature is kept for compatibility (sourceObject is no longer used).

Scope / trade-offs

• Touches only MicrophoneSource.cs and a small additive constructor in RtcAudioSource.cs. Track.cs/Participant.cs/MeetManager.cs unchanged.
• Main-thread pacing trades a little latency/jitter (absorbed by the native queue) for safety — no real-time work on the audio thread, no DSP resample, no clock drift.
• A mid-call device change (caps change after construction) is not auto-recovered: clip.frequency won't match and capture is skipped with a warning until the track is restarted. (Separate concern from this PR.)

Verification

• LiveKit Runtime, PlayModeTests, and Meet Assembly-CSharp all compile clean.
• Not yet run: live publish to a remote receiver (confirm non-choppy audio) and an on-device Bluetooth check — the one-time Utils.Info log reports clip.frequency/clip.channels/native rate for confirmation.

🤖 Generated with Claude Code