Configure native audio source from device config instead of hardcoded defaults#304
Open
MaxHeimbrock wants to merge 1 commit into
Open
Configure native audio source from device config instead of hardcoded defaults#304MaxHeimbrock wants to merge 1 commit into
MaxHeimbrock wants to merge 1 commit 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>
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
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