feat: high-quality resampler by roderickvd · Pull Request #843 · RustAudio/rodio

roderickvd · 2026-02-09T22:05:31Z

Q: How hard could it be to add a high-quality Resample source using Rubato?
A: Almost four weeks of evening work, that's how hard!

It's been surprisingly hard to get the details down. Way more than "just" creating a Rubato instance and processing some buffer. Very grateful for the test cases that were already there - without them, I'd never have gotten this down.

Features

Builder pattern:

// Quick presets
let config = ResampleConfig::fast();
let config = ResampleConfig::balanced();  // same as default()
let config = ResampleConfig::accurate();

// Full customization
let config = ResampleConfig::sinc()
    .sinc_len(nz!(256))
    .interpolation(Sinc::Cubic)
    .window(WindowFunction::BlackmanHarris2)
    .chunk_size(nz!(512))
    .build();

source.resample(target_rate, config);

Polynomial and sinc interpolation: including support for FFT-based resampling for fixed ratios.
Fixed-ratio optimization: auto-detects and switches sinc resamplers to FFT-based or nearest-neighbor processing when the ratio allows. This lowers CPU usage while providing the highest quality.
Span boundary handing: specialized implementation of fix: correct Source trait semantics and span tracking bugs #831 to recreate the resampler on the fly when parameters change at span boundaries, even after seeking.

Performance

Through refactoring of UniformSourceIterator and friends, the performance hit on cargo bench is now 7-8% - which is about the same as the span boundary detection from #831. Considering this PR also adds span boundary detection for the resampler, that means the improved resampling is virtually free.

Initially I had made SampleRateConverter a simple wrapper around the new Resample source. This caused a 20-25% performance hit, and led to my refactoring described next.

Changes

The UniformSourceIterator now is optimized for passthrough, channel count conversion, sample rate conversion, or both. It also inlines the former Take struct (private; not to be confused with TakeDuration) and works with Resample directly.
For UniformSourceIterator to work with Resample directly, it needs to convert an Iterator into a Source. That's from_iter right? Wrong in v0.21: there FromIter is actually something that chains sources together. That seemed counter-intuitive to me. So to bring it in line with Rust idioms:
- FromIter was renamed to Chain (chains sources from an iterator)
- FromFactory was renamed to FromFn (chains sources from a function)
- FromIter now wraps an Iterator<Item = Sample> into a Source
SourcesQueueOutput was copied from fix: correct Source trait semantics and span tracking bugs #831 because it contains peeking fixes necessary to make UniformSourceIterator detect the sample rate correctly when transitioning out of silence.
SampleRateConverter is tagged as deprecated.
ChannelCountConverter now implements Source while keeping a minimum surface for just I: Iterator.
Minor opportunistic refactoring.

Questions

Should we move and rename Resample from src/source/resample.rs to SampleRateConverter in src/conversions/sample_rate.rs and basically replace it?
- This would be breaking due to requiring that I: Source instead of I: Iterator.
- Resample::new could live besides new_poly, new_sinc and the builder.

I might be wrong here (I do not have the span misery mitigations clearly in my head) but can this not get dicey when I:

create an empty chain and put it in a queue

put a 48khz mono source in the queue

queue calls current_span_en get Some(THRESHOLD) on that queue

queue calls sample_rate get 44100 on that queue

queue calls next on chain gets None

queue calls next on the mono source and gets a sample intended for 48khz but playing at 44100.

Now our queue may not call things in this order but what would happen with a user created one?

An alternative design for chain would forbid the empty state by getting the first sample in the new factory, then failing with an error if the first source was empty.

Again im pretty unsure about all this since the span misery has completely left my brain, thanks again for going through all that!

yara-blue · 2026-04-18T14:12:57Z

+        if self.current.is_exhausted() && self.silence_samples_remaining == 0 {
+            if let Some((next, _)) = self.input.next_sounds.lock().unwrap().front() {
+                // Current source exhausted, peek at next queued source
+                // This prevents wrong resampling setup in UniformSourceIterator


there is a subtle race condition here:

call sample_rate, current is exhausted

no next source yet so get self.current.sample_rate()

new source gets appended

next call works without silence placeholder at possibly wrong sample rate

I'd suggest "poisoning" the queue whenever the current is exhausted and we do not have something new yet.

yara-blue · 2026-04-18T14:16:42Z

For now I've already reviewed them so it would just get confusing but in the future please seperate out changes that can be unrelated to multiple PR's. In this case I believe the changes to these files:

uniform,

from_fn,

from_factory,

from_iter

chain()
Should have been separated out, now the whole PR will be held up by their review. It also makes it harder to have the whole PR reviewed (which is part of why it took so long to get this reviewed). For me a 200 line change is something I can sneak in my day somewhere while a large PR like this needs an entire afternoon.

Yara and others added 6 commits February 9, 2026 23:04

rename OutputStream -> OS-Sink, Sink -> Player

8cc0e24

feat: add high-quality resampler

600345d

refactor: use Resample for sample rate conversion

e2aa27e

Replace manual linear-interpolation converter with a Resample-backed implementation and a SourceAdapter for iterator inputs.

fix: conditionally test channel volume

a3751b2

docs: update changelog

43953f3

refactor: replace SampleRateConverter with Resample wrapper

f47aaef

roderickvd requested a review from yara-blue February 9, 2026 22:05

roderickvd added the enhancement label Feb 9, 2026

roderickvd added 2 commits February 9, 2026 23:18

fix: rebase error

f7598a6

fix: clippy lint on 64bit

f5b44ff

roderickvd added 2 commits February 12, 2026 21:20

refactor: split resample into multiple modules

a816d63

style: cargo fmt

c7a0b0e

This was referenced Mar 8, 2026

hifi resampler #670

Closed

get_pos much further ahead than actual playback position #853

Closed

yara-blue requested changes Apr 18, 2026

View reviewed changes

+                      "fast" => ResampleConfig::fast(),
+                      "balanced" => ResampleConfig::balanced(),
+                      "accurate" => ResampleConfig::accurate(),
+                      _ => return Err(format!(

+              fn main() -> Result<(), Box<dyn Error>> {
+                  #[cfg(debug_assertions)]
+                  {
+                      eprintln!("WARNING: Running in debug mode. Audio may be choppy, especially with");


		let args: Vec<String> = std::env::args().collect();

		if args.len() < 2 {

+                  player.sleep_until_end();
+                  let playback_time = playback_start.elapsed();
+                  println!("\nPlayback finished in {:.2}s", playback_time.as_secs_f32());

+              }
+              /// Parse the resampling quality from a string argument
+              fn parse_quality(method: &str) -> Result<ResampleConfig, Box<dyn Error>> {

+                          channels.get() as usize,
+                          rubato::FixedAsync::Output,
+                      )
+                      .map_err(|e| format!("Failed to create sinc resampler: {:?}", e))?;

+                          channels.get() as usize,
+                          rubato::FixedSync::Output,
+                      )
+                      .map_err(|e| format!("Failed to create FFT resampler: {:?}", e))?;

+                      }
+                      // Otherwise we use the constant value.
+                      Some(THRESHOLD)

Conversation

roderickvd commented Feb 9, 2026

Features

Performance

Changes

Questions

Related

Uh oh!

yara-blue commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roderickvd commented Feb 10, 2026

Uh oh!

roderickvd commented Feb 12, 2026

Uh oh!

yara-blue left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

yara-blue commented Feb 9, 2026 •

edited

Loading