kfrlib/kfr: C++20 DSP with SIMD and audio codecs

KFR’s C++20 DSP building blocks

KFR solves the problem of assembling native audio and scientific signal-processing primitives without starting from numerical routines and architecture-specific code. The documented scope covers FFT and DFT operations, FIR and IIR filters, biquads, convolution, sample rate conversion, audio decoding and encoding, and related DSP utilities. The repository contains dedicated examples such as `examples/dft.cpp`, `examples/fir.cpp`, `examples/iir.cpp`, `examples/biquads.cpp`, and `examples/sample_rate_conversion.cpp`, which gives an adopter a concrete place to inspect the API before designing an integration.

The project is aimed at C++ developers working on audio applications, scientific software, and other systems that process sampled data. Its C++20 requirement is meaningful. The README says KFR has no external C++ dependencies beyond a C++20-compatible standard library, while CMake is the build system. This does not mean that every sample project is trivial to integrate. A host application still needs to satisfy the compiler, ABI, platform, and feature requirements described by the project.

KFR’s feature set is broader than FFT alone. The documentation lists real forward and inverse DFT, multidimensional complex and real DFT, DCT type II and its inverse, FFT convolution, and convolution filters. It also lists zero-phase IIR filtering under the name `filtfilt`, elliptic filter design, and independent multi-channel FIR, IIR, and convolution filtering for planar `audio_data`. These are separate implementation surfaces, so an application should identify the exact operation it needs before judging the framework.

FFT, DFT, filters, and audio data flow

The repository is organized around reusable C++ DSP code, with headers under `include/`, sources under `src/`, tests under `tests/`, and examples under `examples/`. This layout indicates a library repository rather than a command-line application. The README does not provide a complete API reference for every operation, but it identifies the central mechanisms available to an integrator: transform routines, filtering functions, convolution, resampling, and audio container or codec handling.

The transform component supports arbitrary-size DFT, not only power-of-two FFT sizes. The release notes for KFR 7.1 identify a low-overhead `ngfft` API with manual memory management. They also describe up to 40% faster power-of-two FFTs and faster processing for sizes with many prime factors. Those statements are release claims, not results from an evaluation performed here. The important integration consequence is that the project exposes both optimized and general transform paths rather than requiring every caller to use the same size or allocation strategy.

Audio support is broader on some platforms than others. The README lists WAV, W64, RF64/BW64, AIFF, FLAC, CAF, ALAC, raw PCM, and decoding for MP3. Windows adds AAC and other Media Foundation formats, while Apple platforms add Core Audio decoding. `audio_filter` is documented as supporting independent multi-channel filtering of planar `audio_data`. The project therefore has both low-level DSP operations and higher-level audio formats, but codec availability remains platform-dependent.

SIMD targets, compilers, and platform boundaries

KFR is designed around SIMD implementations for x86, ARM, and RISC-V. The repository description lists SSE, AVX, AVX-512, ARM NEON, and RISC-V RVV. The README says that ARM, ARM64, and RISC-V targets require Clang or GCC. Its compiler table lists Clang 16+, GCC 11+, MSVC 2022+, and Xcode 13+ as supported toolchains. CMake is used for building, and the repository includes `CMakeLists.txt`, `sources.cmake`, and a `cmake/` directory.

The support matrix is more useful than the headline processor list. Linux, macOS, Android, iOS, Windows, and WebAssembly are listed. On Windows, MSVC support is limited to x86 and x86-64, and the README warns that MSVC 2022 may be slower for DFT and complex algorithms. It states that Clang or GCC should be used when maximum performance is required. On RISC-V, basic support is limited to CPUs with `VLEN >= 128`, Linux, and Clang. These are concrete adoption boundaries, not optional details.

KFR also describes RISC-V support as basic, so a project targeting that architecture should not assume the same maturity as a Linux x86 or ARM target. The documentation says other operating systems, compilers, and CPUs may work but are outside the regular test matrix. For a production application, the target CPU instruction set, compiler version, ABI, and operating system all need to be checked before relying on a particular SIMD path.

Installing KFR through package managers

The README documents package-manager installation commands, but package versions and prebuilt platform coverage do not match across managers. On macOS or Linux, Homebrew is the shortest documented route. This command installs the `kfr` package and may select a prebuilt bottle. The table lists macOS Apple Silicon and Intel releases, plus Linux ARM64 and x86_64 bottles. It also says that Boost and CMake are needed only when building from source.

brew install kfr

The Homebrew table identifies package version 7.1.0 in the repository README, while the project’s recent release list includes KFR 7.2.0. That difference is a practical upgrade-check issue. A reader using Homebrew should inspect the package version returned by the package manager rather than assuming the README table and repository release page are synchronized.

For Arch Linux, the README lists a prebuilt package in the official `extra` repository:

sudo pacman -S kfr

The command installs an x86_64 package and, according to the table, depends only on glibc. The table lists `7.1.0-1` for this package. vcpkg provides another documented option:

vcpkg install kfr

That command is identified as classic mode, and the README also documents `vcpkg add port kfr` for manifest mode. The vcpkg package is built from source and has optional features named `dft` and `capi`. The README says vcpkg is supported on Windows, Linux, and macOS, except Windows ARM64 and Xbox. Conda also has a community channel package named `kfrlib`, documented as `conda install hep-forge::kfrlib`, but it is Linux-only and is not an official conda-forge package.

The README does not give a complete source-build command. It directs readers to the installation documentation and says CMake is used. A first real integration should therefore begin with the package manager appropriate to the target, then inspect the `examples/` directory and the project’s CMake integration documentation.

Example-based first use and maintenance trade-offs

KFR is a library, not a standalone command-line tool. The first practical use is to inspect the examples that correspond to the required operation. `examples/dft.cpp` is relevant to transform work, `examples/fir.cpp` and `examples/iir.cpp` cover two filter families, `examples/biquads.cpp` addresses biquads, and `examples/sample_rate_conversion.cpp` covers resampling. The repository also includes `examples/ccv.cpp` and `examples/window.cpp`, suggesting additional convolution and windowing examples.

The README does not document a copy-and-paste first program or a command that runs an example, so inventing one would misrepresent the project. The correct initial workflow is narrower: obtain KFR, inspect the matching example, confirm that the required feature is enabled in the build, and include the library through the documented CMake setup. The presence of `tests/`, `requirements.txt`, and Catch2 migration in the README indicates that repository development includes automated tests, but the README does not provide a test command.

Maintenance activity is visible in the repository facts. The repository is not archived, and its last push was on 2026-10-12. Releases listed around that date include KFR 7.2.0 on 2026-10-12, KFR 7.1.0 on 2026-08-18, and KFR 7.0.1 on 2025-11-14. This indicates recent release work, but it does not establish compatibility for every host toolchain or package channel. The package-manager table already demonstrates one upgrade cost: Homebrew, vcpkg, Conda, and other channels can expose different versions.

Licensing also needs an early decision. The repository is under GPLv2+, and the README points to a commercial license option. The license choice can affect whether KFR can be linked into a proprietary application, so an organization should review its own distribution model against `LICENSE.txt` before integration. That is a licensing review, not legal advice.

Editorial conclusion

Adopt KFR for a native C++20 audio or scientific application that needs FFTs, FIR or IIR filtering, resampling, or codec integrations, especially when SIMD support across x86, ARM, or RISC-V matters. Do not choose it without checking GPLv2+ compatibility, compiler support, platform packaging, and the documented limits of the target CPU. The first project-specific check is the compiler and CPU combination, followed by inspection of `examples/` and the `dft` or `capi` features needed by the application.

Frequently asked questions

Official sources

1. kfrlib/kfr on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases