Configure native audio source from device config instead of hardcoded defaults#304
Open
MaxHeimbrock wants to merge 3 commits into
Open
Configure native audio source from device config instead of hardcoded defaults#304MaxHeimbrock wants to merge 3 commits into
MaxHeimbrock wants to merge 3 commits into
Conversation
The native (Rust) audio source was created with a hardcoded sample rate (48000) and channel count (2). Microphone frames flow through Unity's audio graph (AudioProbe) at the actual DSP output configuration, which often differs — e.g. with a Bluetooth headset. The Rust source does not resample; it rejects frames whose rate/channels don't match, causing the metadata-mismatch warning and capture failures. Read the source's sample rate and channel count from Unity's output configuration (AudioSettings.GetConfiguration) instead of hardcoded defaults, falling back to the defaults only when Unity can't report one. The base constructor now exposes a device-mode overload (type only) and an explicit overload (type, sampleRate, channels) for sources that generate a fixed format. MicrophoneSource and BasicAudioSource use device mode; BasicAudioSource drops its unused channels parameter. SineWaveAudioSource declares its exact format. If a frame's format still doesn't match (inconsistent Unity report or a runtime output change), drop it with a throttled warning instead of sending a mismatch the native side would error on. Also removes the redundant Microphone.Start in the Meet sample. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Temporary, ~2s-throttled diagnostics to investigate choppy received audio: - RtcAudioSource logs the effective capture sample rate (samples/sec by wall clock) vs the rate declared to the native source. A measured rate that differs from the declared rate means the frame format label is wrong, which would sound fast/slow/choppy on the receiver. - AudioStream logs buffer fill, underrun count, callback count and frames received, to distinguish receive-side starvation from a clean stream. Emitted via Utils.Info so they appear without LK_DEBUG (Utils.Debug is compiled out unless LK_DEBUG is defined). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
MicrophoneSource started the device at the hardcoded DefaultMicrophoneSampleRate and played the looping clip through an AudioSource read on the DSP thread. When the device's actual rate differs from the engine output rate, the clip fills and plays back at different rates, so the read position drifts against the write position and the captured audio becomes choppy. Open the microphone at AudioSettings.outputSampleRate when the device supports it (clamped to the device's reported caps; falling back to the default when the output rate is unknown), so capture and playback run at the same rate. This also aligns the mic rate with the native source rate, which is taken from the same output configuration. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
MaxHeimbrock
force-pushed
the
max/mic-samplerate-device-init
branch
from
af6d96b to
a775e59
Compare
This was referenced Jun 12, 2026
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.
Problem
When the device's audio output configuration differs from the hardcoded defaults — most commonly with a Bluetooth headset — microphone capture fails with
sample_rate and num_channels don't matchand theRtcAudioSourcemetadata-mismatch warning.Root cause:
RtcAudioSourcecreated the native (Rust) audio source with a fixedsample_rate(48000) andnum_channels(2). But captured frames flow through Unity's audio graph (AudioProbe.OnAudioFilterRead) at the actual DSP output configuration. The Rust native source does not resample —NativeAudioSource::capture_framerejects any frame whose rate/channels differ from how the source was configured.Change
RtcAudioSourcenow reads the sample rate and channel count from Unity's output configuration (AudioSettings.GetConfiguration) instead of hardcoded defaults, falling back to the platform defaults only when Unity can't report one.RtcAudioSourceTypeonly) for capture sources whose format is whatever Unity delivers, and an explicit one (type, sampleRate, channels) for sources that generate a fixed, known format.MicrophoneSourceandBasicAudioSourceuse device mode;BasicAudioSourcedrops its unusedchannelsparameter.SineWaveAudioSource(tests) declares its exact format.Microphone.Start(null, …, 44100)in the Meet sample.Scope
This is the focused "get the format right at init" fix. It deliberately does not attempt to hot-swap the source mid-call when the audio device changes after publishing — that's a larger change (it requires recreating + republishing the track, which the binding between a track and its source handle forces) and is better handled separately, e.g. by having
MicrophoneSourcereact toAudioSettings.OnAudioConfigurationChangedand restart capture. A device change during a call will currently drop frames (quiet audio) rather than auto-recover.Verification
livekit-server --dev) and an on-device Bluetooth repro.🤖 Generated with Claude Code