RTLSDR-Airband demodulates several voice channels at once

Receiving voice channels and routing the audio

The project description is short, a multichannel AM and NFM demodulator, and the overview expands it. RTLSDR-Airband receives analog radio voice channels and produces audio streams which can be routed to various outputs. That is the whole product, and the design choices follow from it. A single RTL-SDR dongle delivers a wide slice of spectrum, and the interesting work is splitting that into channels, demodulating each one, and sending the audio somewhere useful. The AM and NFM pairing covers the two modulation types that dominate voice radio, and the multi-channel part is what lets a single receiver cover a band rather than a single repeater. The topics the repository carries line up with the audience, with software-defined radio, RTL-SDR, UHF and VHF, aviation and Raspberry Pi.

The build matrix is the documentation

The README leads with a CI status table, and the table is more informative than a paragraph would be. The continuous integration build runs on x86_64 with Ubuntu 22.04 and 24.04, on ARM64 with the same two Ubuntu releases, on ARM64 with macOS 14, 15 and 26, and on x86_64 with macOS 15 and 26 on Intel. A separate platform build workflow covers the hardware that matters most for this project, ARM64 on Debian Trixie on a Raspberry Pi 4B and ARM32 on Debian Bookworm on a Pi 3B. Published containers are built for five architectures, linux amd64, linux 386, linux arm64, linux arm v6 and linux arm v7. That matrix tells you the project is maintained for both a desktop developer and a headless single board computer, which is the combination you need if you plan to leave a receiver running in a cupboard with a network connection.

The version policy changed at 5.0

The version notes are the part of the README that tells you how the project expects you to consume it, and they are unusual. From version 5.0.0, pull requests are opened directly against the main branch and the unstable branch is no longer used, version tags are created automatically on each merge to main, and a release is created on each major or minor version tag. Checking out main is recommended over using a release artefact, to stay on the latest version. The project also states that it has significantly diverged from the original microtony/RTLSDR-Airband and has been detached, meaning it is no longer a fork. Specific build support for the rpiv1, armv7-generic and armv8-generic targets has been deprecated in favour of a new default called native. And as of version 5.1.0 the licence is GPLv2, which is the single most consequential line in that list for anyone redistributing binaries.

The container compiles the SDR stack from source

The Dockerfile is where the project's care shows. The build stage is Alpine, and the dependency list covers both the DSP stack and the radio libraries: build-base, cmake, git, pkgconf, linux-headers, ca-certificates, lame-dev, libshout-dev, libconfig-dev, fftw-dev, libusb-dev, pulseaudio-dev, soapy-sdr-dev and airspyone-host-dev. There is a comment about Alpine shipping CMake 4, which dropped compatibility with older cmake_minimum_required values, so the policy version is set to allow configuring them anyway. Then the radio libraries are built from source rather than taken from packages. First the rtl-sdr-blog fork of rtl-sdr, cloned at depth one and configured with the install prefix, a Release build type and the kernel driver detached:

git clone --depth 1 https://github.com/rtlsdrblog/rtl-sdr-blog

and the configure step passes the detach option, which is what makes the v4 support work without touching the host kernel driver. After that libmirisdr-4 is compiled and installed the same way, and then the SoapyAirspy device module, because the SoapySDR device modules are not packaged for Alpine. Pinning the exact commit of each dependency at build time, with the commit hash and date logged, is the sort of care that makes a container reproducible.

System tests are Python and run everywhere

The repository carries its own test suite in Python, and the configuration is where the interesting decisions are. The project is named rtlsdr-airband-system-tests, it requires Python 3.11 or newer, and it depends on pytest with the timeout and xdist plugins, numpy and mutagen, the last of which is there to check the metadata of the audio output files. The uv configuration lists an environment for each supported platform, covering x86_64 and aarch64 on Linux, armv7l and armv6l on Linux, and arm64 and x86_64 on macOS. NumPy is pulled from the piwheels index on the 32-bit ARM targets, because the standard wheels do not exist there. The pytest settings set a 120 second timeout and point the test paths at the system tests directory, and the build backend is hatchling with the helpers and tests packaged as a wheel. The linting setup is black with the py311 target, isort on the black profile, and pylint with a list of disabled checks, each one carrying a reason in a comment, such as the missing docstring rules being off for pytest fixtures and dataclasses that are plain data holders.

The repository layout

The top level of the tree is a C++ project with a Python test harness beside it. There is src/ for the implementation, config/ for the runtime configuration, init.d/ for the init scripts, scripts/ for helper scripts, and system_tests/ for the Python test suite. The build is CMake, with a CMakeLists.txt at the root and a Dockerfile beside it, plus a pyproject.toml and a uv.lock for the test dependencies, which is a modern arrangement for a project that started as a plain autotools or make build. The editor and tooling configuration is thorough, with a .clang-format, a .pre-commit-config.yaml, a .devcontainer/ directory for a reproducible development environment, a .vscode/ directory, and a CLAUDE.md for coding agents. NEWS.md holds the release notes, and the licence file sits next to it. The default branch is main, and the project is not archived, with the last push on 2026-10-14.

Where the project stands

The release history is dense at the moment, with three releases in three days, v6.2.0 published on 2026-10-14, v6.1.0 the same day and v6.0.0 on 2026-10-12, which is what a major version bump plus follow-up fixes looks like. The project is written in C++, the licence is GPL-2.0, and the repository is not archived. Two operational notes are worth carrying away. First, the project has moved to the rtl-airband GitHub organisation, and the README points to the old discussions for the move and the licence change, so anyone following an old link is redirected. Second, the recommendation to check out main rather than use a release artefact is unusual but internally consistent, since tags are created automatically on merge to main and releases only appear for the major and minor version tags, so main is where the recent work actually is.

Editorial conclusion

RTLSDR-Airband fits a radio hobbyist or an engineer who wants to listen to several aviation voice channels from one dongle and to run the same setup on a Raspberry Pi or in a container, since the project ships images for five architectures and a cross platform test suite. It does not fit someone who wants a packaged application on a desktop, since the build is a source and container workflow, and it does not fit a project that needs transmit capability, since the tool receives. Before you build, read the version policy, because the project now recommends checking out main rather than using a release artefact, and note the release state, where v6.2.0 and v6.1.0 were both published on 2026-10-14 and the licence is GPLv2.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. rtl-airband/RTLSDR-Airband on GitHub