r8brain-free-src: a header-only C++ resampler with a pluggable FFT back end

A single front end class, r8b::CDSPResampler, over a filter bank

The library exposes one class you are meant to talk to. The documentation says the sample rate converter is represented by the r8b::CDSPResampler class, which acts as a single front end for the whole library, and that you basically do not need to use or understand any other class. Derived classes exist for varying precision levels, including full resolution 16-bit and 24-bit resampling, with r8b::CDSPResampler24 named in the performance discussion.

Internally the resampler works in two stages. The algorithm first produces a 2X oversampled signal, relative to the source sample rate, or to the destination rate when downsampling. It then interpolates using a bank of short fractional delay filters, 8 to 30 taps depending on the precision you ask for, built from polynomial-interpolated sinc functions.

That two stage design is what gives the library its speed position. The readme states that it puts the algorithm into the league of the fastest among the most precise SRC algorithms, with the more precise alternative being only whole number-factored SRC as implemented in the commercial Voxengo r8brain PRO, which can be slower.

All code sits in the r8b namespace, which the readme presents as effectively isolating it from other code, and the code is described as thread-safe with the caveat that a separate resampler object should be created for each channel or stream processed concurrently.

The 2x oversampled sinc fractional delay pipeline in detail

The mechanism underneath the front end class is worth understanding, because it explains both the speed and the precision limits.

Stage one oversamples by a factor of two. Stage two applies a bank of short fractional delay filters, each with between 8 and 30 taps depending on the required precision, and the filter functions are polynomial interpolated sinc functions. Choosing a fractional delay amount per output sample means a different filter from the bank is used for each position, and the interpolated filter smooths the switching between them.

The repository layout reflects the pipeline. CDSPFracInterpolator.h and CDSPSincFilterGen.h are the fractional delay and filter generation pieces, while CDSPHBDownsampler.h and CDSPHBUpsampler.h with their .inc files implement the half band stages on each side of the oversampled signal. CDSPFIRFilter.h, CDSPRealFFT.h, CDSPProcessor.h and CDSPBlockConvolver.h cover filtering, the FFT, the base processor and block convolution.

A stated design goal is reuse. The readme says the objects are structured so they can be created and destroyed frequently in large applications with minimal performance impact, because the initialization-expensive objects, namely the fast Fourier transform and the FIR filter objects, are highly reusable.

Picking an FFT back end: Ooura, Intel IPP or PFFFT

The library ships a default FFT implementation and two alternatives, selected by preprocessor macros.

The default is Ooura FFT. Defining the R8B_IPP macro enables the Intel IPP back end for the FFT functions instead, and the readme states that IPP FFT makes sample rate conversion faster by 23% on average.

#define R8B_IPP 1

If you have no access to Intel IPP, the PFFFT path is described as only slightly slower. There are two macros. R8B_PFFFT enables PFFFT working in single precision resolution, which limits the overall resampler precision to 24-bit sample rate conversions, and the readme explicitly does not recommend R8B_PFFFT for mission-critical professional audio applications because its peak error is quite large. R8B_PFFFT_DOUBLE enables the double precision implementation, which uses SSE2, AVX and NEON intrinsics and yields precision equal to both the Intel IPP and Ooura FFT implementations.

#define R8B_PFFFT 1

Using PFFFT also requires compiling and including the fft/pffft.c or fft/pffft_double.c file that comes with the library in your project build. There is a third macro, R8B_EXTFFT, which is for users who can accept a larger initial processing delay in exchange for efficiency, and which can be defined at the start of the r8bconf.h file or during compilation.

Adding the headers to a build and generating the documentation

There is no package manager step in the readme, because the library is basically header-only and has no dependencies beyond the standard C++ library. You add the headers to your project and include what you need.

The stated requirement is a C++ compiler and a system with support for the double floating-point type with a 53-bit mantissa. The readme notes that no explicit code for the float type is present in the library except in the FFT routines, on the grounds that float based code performed slower on a modern processor, at least in this library.

If you use a pre-C++11 compiler, the added dependency is Windows.h on Windows and pthread.h on macOS and Linux, and you may need to add the Kernel32 library on Windows and the pthread library on macOS and Linux to your project build.

The code comments follow the Doxygen style, and the readme names the local generation step as running the doxygen tool against the file other/r8bdoxy.txt from the library folder.

For a starting point, the repository includes example.cpp at the top level along with a bench directory for benchmarking. The library can also process signals of any scale and loudness, so it is not clamped to the usual minus one to one range.

Asynchronous real-time behaviour and the one object per channel rule

The resampler class was designed as an asynchronous processor. It may produce any number of output samples depending on the length of the input sample data and on the resampling parameters, so the calling code has to feed input until enough output has been produced and then consume any excess output before feeding more input.

Two features make that workable. The resampler removes the initial processing latency automatically, and after the initial moments of processing the output becomes steady, with only minor fluctuations in the length of each output block. For a realtime callback, that means you do not have to model the filter group delay yourself.

The constraint that catches people is the per-stream object rule. The code is thread-safe, but a separate resampler object should be created for each audio channel or stream being processed concurrently. So a stereo pair needs two objects, and a multichannel stream needs as many as it has channels, each carrying its own filter bank state.

For the Windows DLL form of the library, the readme states that a processor with SSE2 support is required, with the Win64 version including AVX2 auto-dispatch code, and that the DLL was compiled with Intel IPP enabled. On non-Windows systems it is preferable to use the C++ library directly.

What the readme does not promise

The documentation has clear edges, and knowing them before you adopt the library saves an afternoon.

First, there is no binding layer for Python or any other scripting language in this repository. The listed ports are Rust, by baadc0de, and WebAssembly, by jlagedo. If your pipeline is Python based, this library means compiling a C++ component yourself, and the Rust and WebAssembly ports do not cover that case.

Second, the performance figures are conditional. The readme cites preliminary tests where r8b::CDSPResampler24 reaches 38 times the core count in Mrops, or 56 with Intel IPP FFT, when converting one channel of 24-bit audio from 44100 to 96000 with a 2 percent transition band on a Ryzen 3700X based 64-bit system, roughly translating to real-time resampling of 860 streams per core, or 1270 with IPP. It also warns that performance for other sample rates may vary greatly.

Third, the comparison advice matters. The readme tells you that when comparing this library to another, make sure the competing library is also tuned to produce a fully linear-phase response, with similar stop-band characteristics and similar sample-timing precision. Without that caveat, a naive benchmark makes this library look better or worse than it is.

Fourth, there is no rollback or versioning story documented, no semantic versioning statement, and no thread-safety guarantee beyond the per-object rule above.

A comparison point that is actually about algorithm class

The most useful comparison in the readme is not with another open source library but with a different class of algorithm. The library is a polynomial interpolated sinc fractional delay filter bank operating on a 2X oversampled signal, and the readme positions it against whole number-factored sample rate conversion, of which the commercial Voxengo r8brain PRO is the named example and is described as more precise but able to be slower.

That difference is the whole design decision. Whole number-factored conversion decomposes the ratio into integer stages and can afford very long filters, which buys stop-band performance at the cost of throughput. The 2X oversampled design instead keeps the filters short, between 8 and 30 taps, and buys throughput at the cost of some ultimate precision.

The readme also notes that this is the same algorithm featured in the free Voxengo r8brain sample rate converter application, which gives you a reference implementation of the same behaviour if you want to hear what the settings produce before you wire the library into your own build.

Other design choices follow the same logic. Using doubles rather than floats is a deliberate performance decision within this library. Reusing the FFT and FIR filter objects across many resamplers is a deliberate memory and latency decision. These are trade-offs, and they are the reason the library reads as a specialist component rather than a general purpose utility.

Licence, credit request and maintenance state

The library is open source under the MIT licence, with a LICENSE file at the repository root. MIT terms place no restriction on using the code in commercial products and require only that the copyright notice and the licence text travel with the source or substantial portions of it.

There is one extra request. The readme asks that you credit the creator of the library in your documentation in the following way: Sample rate converter designed by Aleksey Vaneev of Voxengo. That is a request rather than a licence condition, but it is stated plainly and it is the kind of thing a commercial audio product should honour.

The repository is not archived, and the last push was on 2026-09-30. There are no GitHub releases, so the version history lives in the commit log rather than in tagged artefacts.

Because this is a header-only library with no package manager entry, upgrading means replacing files. That has a real cost: your build is coupled to the exact headers you vendored, and any change to the library lands as a source diff in your own tree rather than as a dependency bump. Anyone adopting it should decide early whether to vendor the headers or to pin a commit, because that choice determines what an upgrade looks like.

Editorial conclusion

Adopt r8brain-free-src when you are writing C++ and need sample rate conversion or 1D interpolation with a vendorable MIT header-only library and can tolerate compiling it into your own build. Do not adopt it if you need Python bindings, a realtime safe guarantee, or a resolution beyond what the filter bank macro selection gives you, since the readme notes the single precision PFFFT path is not recommended for professional work. Before committing, decide on the FFT back end macro in r8bconf.h, check that double precision floating point is available on your target, and measure your own conversion ratio rather than relying on the Ryzen 3700X figures the readme quotes.

Frequently asked questions

Official sources

1. avaneev/r8brain-free-src on GitHub
2. Issues
3. License: MIT
4. README