libsamplerate does the rate conversion, and nothing else

One job, described precisely

libsamplerate, also known as Secret Rabbit Code, is a library for performing sample rate conversion of audio data, and the README states the version as 0.2.2. That narrowness is the point rather than a limitation to apologise for. The library sits in a pipeline and does one transformation: it takes audio data at one sample rate and produces audio data at another, leaving decoding, file handling, mixing and playback to whoever links it. The repository is organised around that boundary. The src/ directory contains the source code for the library itself, docs/ contains the documentation, examples/ contains examples of how to write code using libsamplerate, tests/ contains programs which link against libsamplerate and test its functionality, and Win32/ contains files to allow libsamplerate to compile under Win32 with the Microsoft Visual C++ compiler. The top level also holds include/ for the public headers and an AUTHORS file, and the project is published under the BSD-2-Clause licence with a COPYING file at the root.

The autotools path is the primary build

The README gives the classic three command build for platforms which have a Bourne compatible shell, an ANSI C compiler and a make utility, and says it should require no more than the following three commands. The list actually contains four lines because the install step is separate:

autoreconf -vif
./configure
make
make install

That is the whole build for a Unix-like system, and the surrounding files in the tree explain what is driving it. There is a configure.ac, an autogen.sh, a Makefile.am, a libsamplerate.spec.in for RPM packaging, a samplerate.pc.in which is the template for the pkg-config file, m4/ for the autoconf macros, and a config.h.cmake for the CMake path. The library is written in C and the source is the original author's work, since the README credits libsamplerate as having been written by Erik de Castro Lopo. The autotools route is the one with the most scaffolding in the repository, which tells you it is the one the project expects most people to use, and it is the route that also has to work on the widest range of Unix-like systems including the older ones.

CMake is available and is described as the newer build

There is a new CMake-based build system available, and the instructions are a conventional out of source build:

mkdir build
cd build
cmake ..
make

Two flags are called out. cmake -DCMAKE_BUILD_TYPE=Release .. produces a release build, and cmake -DBUILD_SHARED_LIBS=ON .. builds a shared library rather than a static one. The BUILD_SHARED_LIBS option is worth understanding before you pick it, because a shared build changes how the library is found at runtime rather than how it is compiled, and a project that mixes a shared libsamplerate with a statically linked dependency can end up with two copies of the library in one process. The CMakeLists.txt at the root and the cmake/ directory hold the configuration, and there is a separate CMakeLists.txt in examples/ so the example programs build with the same tool. The presence of both build systems, with the CMake one flagged as newer, is a common pattern in established C libraries and it means you can adopt whichever one your project already uses without changing the rest of your build.

Windows and macOS have their own paths

Windows is handled by a dedicated directory of files to allow libsamplerate to compile under Win32 with the Microsoft Visual C++ compiler, and there are detailed instructions for building on Win32 in the file docs/win32.md. The presence of the Win32/ directory alongside a separate detailed guide is a decent indicator of how much friction a non autotools build path can be, and it is worth reading the document before assuming the CMake path will work unchanged on Windows, since the Visual C++ compiler and the Unix toolchain have different expectations. macOS is treated as the simple case, with the README saying that building on macOS should be the same as building it on any other Unix platform, which means the autotools sequence above applies unchanged. Everything else that has a Bourne compatible shell, an ANSI C compiler and make follows the same path, which is a wide swath of systems including the embedded Linux boards where a small C library is often the only practical option.

The examples show two usage shapes

The examples directory contains audio_out.c with its accompanying audio_out.h, a timewarp-file.c and a varispeed-play.c, and its own CMakeLists.txt so it builds with the project. Read as a set, they describe two different relationships between the resampler and the rest of a program. The timewarp-file example is the file to file case, where the input and output are files and the resampler sits in the middle of a conversion. The varispeed-play example is the streaming case, where the resampler is in a playback path with a speed factor applied, and the audio_out pair abstracts the output device so the same code can drive an audio backend. The shared header suggests the second example is also a demonstration of how to structure an application around the library, with the output side behind an interface. The examples directory in the tree is a small, well chosen set rather than a large one, which is the right balance for a library whose API surface is narrow and whose tricky part is the algorithm rather than the calling convention.

Maintenance state, and what a 2021 release number really means

The repository is not archived and the last push was on 2026-08-13, so the code is still receiving work. The release history is the part that deserves a second look, though. The recent releases are 0.2.2 from 2021-09-05, 0.2.1 from 2021-01-23 and 0.2.0 from 2021-01-21, so the last tagged release predates the most recent commits by roughly five years. For a library like this that is a normal and largely healthy situation, because the code is small, the algorithm is old and well studied, and the format of the public API is unlikely to change. But it does change how you should read the version number. 0.2.2 describes the API and behaviour of a 2021 release, and a distribution that ships a patched or newer build may carry a different version string depending on how its packager labelled it. The repository carries a ChangeLog and a NEWS file at the top level, which are the places to look for what changed when, and the build status table shows the master branch built by GitHub Actions, with the branch described as actively built.

Editorial conclusion

Adopt libsamplerate when your program needs to resample audio between rates and you want a small, long established C library rather than a resampler of your own, especially if you already build with autotools or CMake. Do not adopt it expecting a new feature set, since the last tagged release is 0.2.2 from 2021 and the project describes itself in the present tense as a library for one job. Verify first that your platform has a working build path, using the Win32 instructions if you are on Windows, that your toolchain can run the autotools sequence, and that the version you pick up from your distribution still behaves the way your pipeline expects.

Frequently asked questions

Official sources

1. libsndfile/libsamplerate on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases