feat(audio): use device default sample rate and always downsample#1084
Merged
cjpais merged 2 commits intocjpais:mainfrom Mar 19, 2026
Merged
feat(audio): use device default sample rate and always downsample#1084cjpais merged 2 commits intocjpais:mainfrom
cjpais merged 2 commits intocjpais:mainfrom
Conversation
instead of forcing the microphone to open at 16kHz (which can cause issues with bluetooth codecs, some ALSA drivers, and other devices that advertise 16kHz support but produce suboptimal audio), use the device's native/default sample rate and let the existing FrameResampler downsample to 16kHz for the whisper pipeline. the resampling infrastructure (rubato FftFixedIn) already exists in run_consumer() and short-circuits when in_hz == out_hz, so devices that natively default to 16kHz are unaffected.
8 tasks
some ALSA/PipeWire drivers support default_input_config but have a broken supported_input_configs implementation. fall back to the default config instead of propagating the error. also add a warn log when no config matches the device's default rate.
Owner
|
Thank you, I think this is the right fix. I see #1083 but prefer this I think if it works universally |
This was referenced Mar 18, 2026
🧪 Test Build ReadyBuild artifacts for PR #1084 are available for testing. Download artifacts from workflow run Artifacts expire after 30 days. |
This was referenced Mar 18, 2026
Owner
|
I know we don't have a lot of testing on this, and I'm a bit concerned it could break something, but I think it's a good change for now. Hopefully it will fix some outstanding issues. I think we can pull it in and hit issues in prod if any. |
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
2 participants
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.
Before Submitting This PR
Human Written Description
currently we force the mic to open at 16kHz whenever the hardware advertises support for it. this can produce suboptimal audio on devices where 16kHz is technically in the supported range but isn't the native rate, ie bluetooth codecs, certain ALSA drivers on linux, some USB mics. cj suggested using the device's default sample rate and always downsampling instead, since the resampling pipeline already exists and handles it well.
this PR changes
get_preferred_config()to query the device's default rate and pick the best sample format at that rate, letting the existingFrameResampler(rubato FFT) downsample to 16kHz. devices that already default to 16kHz are unaffected (resampler short-circuits).Related Issues/Discussions
per cj's suggestion in #747 (comment)
Testing
AI Assistance
If AI was used: