ARDFTSRC
A rust implementation of the Arbitrary Rate Discrete Fourier Transform Sample Rate Converter (ARDFTSRC) algorithm.
ardftsrc is a streaming audio sample-rate converter for interleaved audio streams, and is appropriate for both realtime and offline resampling.
Generally ardftsrc is preferred over other resamplers when quality is paramount. Although it is generic over both f32 and f64, it is highly recommended to use it with f64, even when processing an f32 audio stream.
It is more compute and memory intensive than other resamplers, so consider rubato if you want more efficiency.
Quick Start
Use process_all to resample a complete interleaved audio stream.
use ;
Chunk Streaming
There are two streaming modes, chunk based and sample based.
Use chunk streaming when you can control both read and write buffer sizes. Query input_chunk_size() and output_chunk_size() and size your input and output slices to the sizes required. The chunk API is more efficient and is preferred when you are able to control the buffer sizes.
process_chunk(...)for each chunk, input and output slice sizes should matchinput_chunk_size()andoutput_chunk_size()- Call
process_chunk_final(...)for the final chunk, it can be undersized. finalize(...)must be called once per stream to emit delayed tail samples and reset stream state.
To end the stream early, you can always just stop and call reset() on the stream.
use ;
Sample Streaming
Use sample streaming when you do not control buffer sizes. This API supports arbitrary input lengths (including single frames / samples), and handles internal chunking for you.
- Call
write_samples(...)with any incoming input size and callread_samples(...)to drain available output. - For multichannel streams, samples must be written interleaved.
- Before calling
finalize_samples(...)all previously written samples must be frame aligned. - Call
finalize_samples(...)once at end-of-stream, then keep callingread_samples(...)until it returns0.
Expect bursty read behavior when writing small numbers of samples at a time. To end the stream early, you can always just stop and call reset() on the stream.
use ;
Gapless Context
For adjacent tracks, you can set edge context before processing:
pre(...): tail samples from the previous trackpost(...): head samples from the next track
post(...) may be called any time while the current stream is still active, but it must be
set before process_chunk_final(...) (chunk API) or finalize_samples() (samples API).
This enables live gapless handoff: while track A is streaming, once track B is known you can
call post(...) on A with B's head samples so A's stop-edge uses real next-track context.
Both buffers must be interleaved and channel-aligned.
Batching
Use batching when you have multiple full tracks to convert with the same configuration.
batch(...): processes each input as an independent stream (no context shared between tracks).batch_gapless(...): preserves adjacent-track context for gapless album-style playback.
Both APIs accept &[&[T]] (a list of interleaved, channel-aligned tracks) and return Vec<Vec<T>> in the same order as input.
Enable the rayon feature to parallelize work across tracks.
use ;
Quality Tuning and Presets
ARDFTSRC is built for quality over speed, and despite supporting both f32 and f64 should almost always be run as f64. To resample f32 audio, it is recommended to convert f32 samples to f64, resample them using ARDFTSRC as f64, then convert back to f32.
If you want speed over quality, consider using a sinc resampler such as rubato.
Presets are pre-vetted Config for various quality levels.
let config = PRESET_GOOD
.with_input_rate
.with_output_rate
.with_channels;
| Preset | Parameters | Recommended use | Performance |
|---|---|---|---|
PRESET_FAST |
quality=512 bandwidth=0.8323 |
Fast preset for realtime workloads. Prefer a sinc resampler such as rubato. |
TODO |
PRESET_GOOD |
quality=2048 bandwidth=0.95 |
Balanced preset for realtime quality. | TODO |
PRESET_HIGH |
quality=65536 bandwidth=0.97 |
High quality for offline or quality-focused realtime use. | TODO |
PRESET_EXTREME |
quality=524288 bandwidth=0.9932 |
Maximum quality, intended for offline use. | TODO |
Feature Flags
| Flag | Enables | Default |
|---|---|---|
rayon |
Parallel processing (channel and track parallelism) | No |
avx |
FFT AVX backend | No |
sse |
FFT SSE backend | No |
neon |
FFT NEON backend for ARM / Mac | No |
wasm_simd |
FFT WebAssembly SIMD backend | No |
Contributing
Contributions are welcome!
Architectural Overview
At a high level there are two layers:
ArdftsrcCore<T>is the core DSP engine. It owns FFT and runs the core ARDFTSRC algorithim. It is private.Ardftsrc<T>is the public orchestrator. It owns oneArdftsrcCoreper channel, and routes incomming interleaved audio to channel-specificArdftsrcCore<T>cores.
Interaction model:
- Caller uses
ArdftsrcAPIs (process_chunk,write_samples,process_all, etc.) with interleaved audio. Ardftsrcmaps that stream into per-channel slices and routes each slice to the correspondingArdftsrcCore. There is one core per channel.- Each
ArdftsrcCoreadvances independently (but in sync), thenArdftsrccombines channel outputs back into interleaved form.
Golden Hashes
The golden_hashes test validates resampler determinism against checked-in golden outputs in test_wavs/golden_hashes.<arch>.json. It is intended to catch unintended behavior changes.
Run it with:
To regenerate test_wavs/golden_hashes.<arch>.json:
Updates to test_wavs/golden_hashes.<arch>.json are allowed, but only when accompanied by verifiable quality improvements demonstrated with the HydrogenAudio SRC test suite.
AI Usage Policy
AI use is allowed for the following:
- Code exploration and understanding
- Generating tests
- Creating normal code / function blocks as long as the code is then manually and carefully hand-edited by a human
Development TODOs:
- It is very sensitive to the allocatior (mimalloc gives 50% performance improvements), so we are perhaps thrashing the allocator somewhere that we didn't expect.
- the samples API does some allocations on every read / write we could avoid, fix this at the same time as #5, since it's related to orchestrating interleaved samples to planar.
- Add support for
phaseconfig. - Calc performance metrics and post links
- Investigate moving to a an audioadapter based interface, instead of always assuming interleaved.
- Add bindings to other languages, python, ts (wasm) etc.