# CamillaDSP puts FIR and IIR filtering in one YAML pipeline

> CamillaDSP is a Rust command line audio engine for active crossovers, room correction and general filtering, and it fills a gap the README names plainly: EqualizerAPO does FIR and IIR on Windows only, while BruteFIR does FIR on Linux without IIR. The configuration is one YAML file describing a pipeline of filters, mixers and processors, and the backends span ALSA, PulseAudio, PipeWire, Jack, WASAPI, ASIO and CoreAudio.

**HEnquist/camilladsp** — A flexible cross-platform IIR and FIR engine for crossovers, room correction etc.

- Repository: https://github.com/HEnquist/camilladsp
- Website: https://henquist.github.io/
- Stars: 1,089 · Forks: 106
- Language: Rust
- License: GPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/henquist-camilladsp

## The gap the project exists to fill

The background section in the README explains the design, and it is a good place to start because it tells you what CamillaDSP is not trying to be. The purpose is to enable audio processing with combinations of FIR and IIR filters. That functionality is available in EqualizerAPO, but for Windows only. For Linux, the best known FIR filter engine is probably BruteFIR, which works very well but does not support IIR filters. The goal that follows is to provide both FIR and IIR filtering for Linux, Windows and macOS, to be stable, fast and flexible, and to be easy to use and configure. So the tool is aimed at the person who has measured a room or designed a crossover and wants the resulting filters running in the signal path, on whichever of the three platforms they happen to use. It is a headless engine in that sense, and the graphical control is a separate project in the same family.

## A pipeline of filters, mixers and processors

The processing pipeline consists of any number of filters and mixers, and the configuration is a YAML file. The mixers route audio between channels and change the number of channels in the stream, which is how a multichannel source is adapted to whatever the output device expects. The filters can be both IIR and FIR, with IIR implemented as biquads and FIR using convolution via FFT and inverse FFT, and a filter can be applied to any number of channels. The documented filter set covers gain, volume, loudness, delay, FIR, IIR, dither, limiter and the general difference equation, which is the escape hatch for anything the named filters do not cover. The processor set adds a compressor and a noise gate. The pipeline structure itself is a sequence of filter steps and mixer or processor steps, with a rule that a filter step contains only filters and a mixer step contains only mixers and processors, and there is support for tokens in names so a value can be substituted into a name, and for bypassing individual steps without removing them from the file.

## Seven backends, chosen at compile time

Audio is captured from a capture device and sent to a playback device, and the supported backends for both directions are listed as ALSA, PulseAudio, PipeWire, Jack, Wasapi, ASIO and CoreAudio. The Cargo manifest shows how that flexibility is implemented, and the answer is Cargo features rather than runtime detection. The default feature set is only the websocket interface, and the backends are enabled as Cargo features:

```toml
[features]
default = ["websocket"]
threaded-alsa = []
pulse-backend = ["libpulse-simple-binding", "libpulse-binding"]
pipewire-backend = ["pipewire"]
cpal-backend = ["cpal"]
jack-backend = ["cpal-backend", "cpal/jack"]
bluez-backend = ["zbus"]
asio-backend = ["asio-sys"]
```

The platform dependencies follow the same conditional structure, with the alsa, nix, zbus and pipewire crates under a Linux target block, the coreaudio-rs and objc2 crates under macOS, and wasapi, windows and asio-sys under Windows. The practical consequence is that a build is specific to the platforms and backends you enable, which is how a single source tree serves a Raspberry Pi, a Windows workstation and a Mac. The repository also ships separate backend notes as markdown files for ALSA, CoreAudio, PipeWire and WASAPI, which is the right way to document the parts that differ most between systems, and a Cross.toml for cross compilation plus armv6 and armv7 Dockerfiles for embedded targets.

## Latency is a chunk size decision

All processing is done in chunks of a fixed number of samples, and the trade-off is stated in one sentence. A small number of samples gives a small in-out latency, while a larger number is more efficient. This is the central tuning decision in a real-time filter engine, because the chunk size sets the delay between the audio entering the machine and the filtered audio leaving it, and it also determines how much work the engine does per unit of time. A large chunk is more efficient but adds latency, which matters more in a live performance than in a playback chain, and it also affects how quickly a configuration change can take effect. The same mechanism explains why the engine is not a plugin host and why it is a separate process: the audio device is owned by one process, that process owns the chunk timing, and the filters are applied inside the chunk loop. The benches/ directory and the testing.md and stepbystep.md documents in the repository are where the measurement side of this lives.

## The ASIO feature changes the licence

This is the one legal detail that surprises people, and the README gives it its own section. CamillaDSP is free software that can be redistributed and modified under either of two licences, the GNU General Public License version 3 or the Mozilla Public License version 2.0, and the Cargo manifest records it as GPL-3.0-only OR MPL-2.0. The catch is the optional ASIO backend, which depends on the ASIO SDK, and that SDK is licensed under the GNU General Public License version 3. When CamillaDSP is built with the asio-backend feature enabled, the resulting binary is subject to the GPLv3 licence only, and the MPL 2.0 option does not apply to binaries that include ASIO SDK code. In practice that means a Windows build with ASIO cannot be distributed under the more permissive of the two options, and the choice is made at build time by which features you enable rather than by any runtime setting. The project also states the software is provided as is without any warranty, that you use it entirely at your own risk, and points at the disclaimer and liability sections of both licences.

## The family of projects around the engine

The README distinguishes the engine from the ecosystem around it, and the ecosystem is where most people will meet the project. CamillaGUI is a web based interface for configuring and controlling the engine, which is the friendly front end to a command line core. pyCamillaDSP is a Python library for interacting with the engine over its websocket interface, and pyCamillaDSP-plot is a Python library for visualising configurations and filter responses, which is the tool that answers whether the filter set you just wrote does what you intended. camilladsp-config is a repository of example configurations and scripts for common use cases, so a crossover for a two way speaker is a configuration you start from rather than write from scratch. camilladsp-controller is a controller for automatic sample rate switching, and camilladsp-setupscripts holds automated setup scripts for getting the whole stack running. The websocket support is not an afterthought, since it is the only default feature and it is what makes the other tools possible.

## Resampling, rate adjust and the REW bridge

Two configuration areas deserve a mention because they are where a real installation gets its value. Resampling is a first class section of the configuration, and rate adjust has a section that explains both the problem it solves and how it works, which is unusual and welcome, since rate adjustment in a multi device setup is where a naive implementation turns into a resampling mismatch between capture and playback. The bridge to existing measurement workflows is the filter support from REW, and the repository contains a translate_rew_xml.py script plus a set of filter text files, so filters exported from Room EQ Wizard can be brought into a configuration rather than retyped. The supporting documentation in the repository is unusually complete for an engine of this kind, with filterfunctions.md describing the available functions, sample_formats.md covering the audio formats, tested_devices.md listing hardware that has been tried, a FAQ.md, a troubleshooting.md and a websocket.md for the control interface. The exampleconfigs/ directory holds ready made configurations, and stepbystep.md suggests the intended way to learn the tool is by following a worked procedure.

## Conclusion

CamillaDSP fits a speaker builder or measurement enthusiast who wants crossover and correction filters running in real time across Linux, macOS and Windows from a versioned configuration file, and the fact that the whole setup is YAML means the filter set can live in version control next to the measurement that produced it. It does not fit a Windows user who needs a graphical equalizer front end, because the engine is a command line application and the graphical interface is a separate project, and it does not fit a distributor who needs a permissive licence on a build that includes ASIO. Before you build, read the licence section, because the default dual GPLv3 or MPL2.0 option changes to GPLv3 only the moment the asio-backend feature is enabled, check the backend notes in the repository for your system, and pin a version, since the stable line is v4.1.3 from 2026-04-09 while v5.0.0-beta.1 was published on 2026-10-08 and the last push was on 2026-10-14.

## FAQ

### What is CamillaDSP used for?

It is a real-time audio processing engine for active crossovers, room correction and general filtering, applying combinations of FIR and IIR filters with mixers and processors, configured entirely in a YAML file.

### Which audio backends does CamillaDSP support?

ALSA, PulseAudio, PipeWire, Jack, Wasapi, ASIO and CoreAudio are supported for both capture and playback, and each one is selected as a Cargo feature at build time, with websocket as the only default feature.

### What licence is CamillaDSP under?

It is dual licensed as GPL-3.0-only OR MPL-2.0, but a build that enables the asio-backend feature, because the ASIO SDK is GPLv3, can only be distributed under GPLv3.

### How does CamillaDSP keep latency low?

All processing is done in chunks of a fixed number of samples, and the chunk size is the trade-off: small chunks give small in-out latency while larger chunks are more efficient.

### Is CamillaDSP still being developed?

The repository is not archived and the last push was on 2026-10-14, with v5.0.0-beta.1 published on 2026-10-08 and the stable line at v4.1.3 from 2026-04-09.

## Sources

- [HEnquist/camilladsp on GitHub](https://github.com/HEnquist/camilladsp)
- [License: GPL-3.0](https://github.com/HEnquist/camilladsp/blob/master/LICENSE)
- [Project website](https://henquist.github.io/)
- [README](https://github.com/HEnquist/camilladsp/blob/master/README.md)
- [Releases](https://github.com/HEnquist/camilladsp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/henquist-camilladsp