# welle.io: a DAB and DAB+ receiver for RTL-SDR, Airspy and SoapySDR hardware > welle.io is a C implementation of a DAB and DAB+ software defined radio receiver with a Qt GUI and a welle-cli command line tool, covering RTL2832U, Airspy R2 and Mini, raw I/Q files and any SoapySDR device. It suits a listener who wants broadcast digital radio on a cheap dongle, and it does not suit a receiver that needs the HF bands or an antenna system that comes with the software. **AlbrechtL/welle.io** — A DAB/DAB+ Software Defined Radio (SDR) - Repository: https://github.com/AlbrechtL/welle.io - Website: https://www.welle.io - Stars: 754 · Forks: 150 - Language: C - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/albrechtl-welle-io ## A receiver that treats the radio as a device, not a feature welle.io is an implementation of an SDR DAB and DAB+ receiver. The repository holds the source, and the project website at welle.io carries the user oriented documentation, which is the split the README asks for. The interesting part is the hardware abstraction. The supported device list is not a single dongle but a range of backends. The RTL2832U is supported through rtl-sdr and rtl_tcp, so a local USB stick and a network-attached rtl_tcp instance both work. The Airspy R2 and Airspy Mini are supported, with a stated limitation that the Airspy HF+ is not supported due to limited bandwidth. An I/Q RAW file is a supported input, which means recorded samples can be replayed without hardware. And SoapySDR covers everything SoapySDR, gr-osmosdr and uhd support, with SoapyOsmo and SoapyUHD bridging the two ecosystems, and the README notes that the list of devices there is too long to enumerate and points to the SoapySDR and SoapyOsmo wiki lists instead. The two specific device notes are practical rather than theoretical. For a LimeSDR the README says to connect the antenna to the RX1_W port and set the SoapySDR antenna option to LNAW, with SoapySDRUtil --probe=driver=lime offered as a way to see the other options. For a USRP the driver argument is driver=uhd, with the antenna and clock source options configured as well, and SoapySDRUtil --probe=driver=uhd listed as the way to see the available values. And there is the constraint that applies to every device: the SDR must be tunable to the DAB+ frequencies. No software can make a tuner that cannot reach those bands receive them, and the README says so directly. ## The CLI is the part you can script, and it has its own Docker image welle.io is primarily a GUI program, and the README says as much: since welle.io is a GUI program, simply start it. The command line parameters are few, and they are diagnostic rather than controlling. The help and version flags are -h with --help and -v with --version. The --dump-file parameter records DAB frames in the .mp2 format or DAB+ superframes with RS coding in the .dab format, and the README points out that such a file can be used to analyse X-PAD data with XPADxpert. The --log-file parameter takes a log file name and redirects all log output texts to it. The keyboard shortcuts show what the GUI is for. Number keys and Ctrl combinations select a station from the list, with 0 for station 10 and Ctrl+1 for station 11, and the media keys start, stop and pause playback. N and P move to the next and previous station in the list, M mutes, and Ctrl+Up and Ctrl+Down change the volume. For a headless or scripted use, the tool is welle-cli, and the repository carries a dedicated Dockerfile for it. The image is based on ubuntu:24.04, installs the same development libraries the source build needs, clones the repository, and configures the build with a specific option. ```dockerfile FROM ubuntu:24.04 LABEL maintainer "albrechtloh@gmx.de" LABEL description "welle-cli Docker image" ``` The build line in that Dockerfile is where the interesting flag appears, with cmake configured to turn the GUI off while building the command line tool. ```bash cmake ../ -DBUILD_WELLE_IO=off -Wno-dev && \ make -j 12 && \ make install ``` The image exposes port 2000 and its default command is a shell rather than the receiver, so a container based setup is something you drive interactively. The repository also ships a welle-cli-munin.py file and a welle-cli.desktop entry, which is the shape of a tool meant to feed a monitoring system, and a Munin style script expects to query a running instance. ## Building from source needs Qt 6.8 and a long list of codec libraries The build dependencies are listed explicitly, and they describe what the receiver actually does. The required libraries are Qt 6.8 or above, libfftw3, libfaad, librtlsdr, libusb, libmpg123, libairspy, libmp3lame and libsoapysdr. Reading that list tells you the signal chain. libfftw3 is the fast Fourier transform library, which is what a wideband DAB receiver needs to do its channelisation. libfaad is the AAC decoder, which handles the audio in DAB+. librtlsdr and libairspy are the two most common tuner backends, libusb is the transport underneath them, and libmpg123 and libmp3lame handle the audio layer. libsoapysdr is the abstraction that makes the long list of hardware possible. On Debian and Ubuntu the recipe is four steps, tested on Ubuntu 24.04. The base requirements, then the non-Qt packages, then Qt itself through the online installer, then the clone. ```bash sudo apt install git build-essential ``` ```bash sudo apt install libfaad-dev libmpg123-dev libfftw3-dev librtlsdr-dev libusb-1.0-0-dev mesa-common-dev libglu1-mesa-dev libpulse-dev libsoapysdr-dev libairspy-dev libmp3lame-dev libflac++-dev xxd ``` ```bash git clone https://github.com/AlbrechtL/welle.io.git ``` The Qt step needs the online installer rather than a distribution package, and the README recommends the newest Qt version, plus three additional Qt modules: the Qt 5 Compatibility Module, Qt Charts and Qt Multimedia. The final two steps are graphical, since the project is opened in Qt Creator from the welle.io.pro file and built from there. The dependency list in the Dockerfile is almost identical to the apt line in the README, which is a good sign that the documented recipe and the container build do not drift. The one difference is that the container adds cmake and plocate and does not add the Qt pieces or xxd, which is consistent with it building welle-cli rather than the GUI. ## Packaging is uneven, and the README is honest about where The distribution story varies a lot by platform, and the README is unusually direct about the weak spots. Windows has a stable installer for x86_64 and a CI badge for it. Linux is the best served platform: a Flatpak for x86_64 and arm64, a list of supported distributions through Repology, Debian and Ubuntu packages for 19.04 and later, and RPM Fusion packages for Fedora 35 and later. The Flatpak is the recommended option, and the reason given is specific: the Linux distribution packages of welle.io can be outdated. The Debian and Ubuntu route is a single apt install of welle.io, and the Fedora route goes through the RPM Fusion sources, where the release packages are installed first and welle.io follows with a dnf install --refresh of welle-io. macOS and Android are the two places the project says it has given up for now. Both are described as unmaintained, currently, and both are pinned at version 2.4, with the macOS installer available as a release and the note that it supports Intel processors only. macOS does have a MacPorts route. FreeBSD has a pkg install line and a Dockerfile.raspberrypi sits at the top level for the Raspberry Pi. The Android situation has a specific reason given in the build status section: the APK build workflow is currently disabled because a new, skilled maintainer for the Android package is required to fix a bug in the workflow, with a link to the issue. That is a project saying that a platform is not supported until someone owns it, which is a healthier statement than a stale release page. For developers there are nightly builds for Windows and Linux, hosted separately, and the README warns that those builds are automatically created and untested. ## A last push in 2026, but a release line that stopped in 2025 The maintenance picture has a shape that is easy to misread, so it is worth separating two things. The last push was on 2026-10-22, so the source is receiving changes right now. The recent release list, though, stops earlier: v2.7 from 2025-03-16, v2.6 from 2024-12-17, and v2.5 from 2024-10-08. The releases are spaced months apart, and the most recent one is about nineteen months old. So the repository is not abandoned and the released version is not the whole of the project. A user who wants the current behaviour rather than a stable point should look at the developer builds, with the README's warning in mind that they are automatically created and untested. A user who wants a known state should take the last tagged release and accept the features and the platform coverage of that release, which on macOS and Android means version 2.4. The licence is recorded as a custom licence that GitHub cannot classify, with the terms in the LICENSE file and a COPYING file at the top of the repository, alongside an AUTHORS file and a THANKS file. Since the project is widely packaged by distributions, the exact terms matter for anyone redistributing it, and the repository is explicit that the file is where the answer is. The project also ships a Flatpak manifest, io.welle.welle-gui.yml, and an AppStream metadata file, io.welle.welle-gui.appdata.xml, which is the packaging surface that makes the Flathub listing possible, and a windows_installer.iss file for the Windows installer. The.github directory holds the CI workflows for the Linux, Windows and Android builds. ## Conclusion welle.io fits a listener who has an RTL-SDR dongle or an Airspy and wants DAB and DAB+ broadcast radio on the desktop, in a GUI for browsing the service list or in welle-cli for feeding a recording or monitoring setup. It does not fit someone who needs the HF bands, since the Airspy HF+ is excluded for limited bandwidth, or a platform that needs an active maintainer, since the Android build workflow is disabled and the macOS and Android packages are described as unmaintained at version 2.4. Before installing, confirm your tuner is in the supported hardware list and that it can be tuned to the DAB+ frequencies, and pick the Linux package deliberately, because the README recommends the Flatpak since the distribution packages for welle.io can be outdated. ## FAQ ### What SDR hardware does welle.io support? The supported list covers RTL2832U through rtl-sdr and rtl_tcp, Airspy R2 and Airspy Mini, I/Q RAW files, and any device supported by SoapySDR, gr-osmosdr or uhd through SoapyOsmo and SoapyUHD. The Airspy HF+ is excluded because of limited bandwidth, and the device must be tunable to the DAB+ frequencies. ### How do I install welle.io on Linux? The README recommends the Flatpak, noting that the Linux distribution packages of welle.io can be outdated. Other options are Debian or Ubuntu 19.04 and later with apt install welle.io, Fedora 35 and later through the RPM Fusion sources, a full list of supported distributions on Repology, and FreeBSD with pkg install welle.io. ### What does the welle-cli Dockerfile build? It builds the command line tool rather than the GUI, starting from ubuntu:24.04, and configures the build with cmake using the BUILD_WELLE_IO=off option before running make. The image exposes port 2000 and its default command is a shell. ### Is welle.io available on macOS and Android? Both are described as unmaintained currently, and both are pinned at version 2.4, with the macOS build supporting Intel processors only. The Android APK build workflow is disabled because a new, skilled maintainer for the Android package is required to fix a bug in the workflow. ### What libraries does building welle.io from source require? Qt 6.8 or above plus the Qt 5 Compatibility Module, Qt Charts and Qt Multimedia, along with libfftw3, libfaad, librtlsdr, libusb, libmpg123, libairspy, libmp3lame and libsoapysdr. The Debian and Ubuntu recipe in the README lists the corresponding dev packages. ## Sources - [AlbrechtL/welle.io on GitHub](https://github.com/AlbrechtL/welle.io) - [Issues](https://github.com/AlbrechtL/welle.io/issues) - [Project website](https://www.welle.io) - [README](https://github.com/AlbrechtL/welle.io/blob/master/README.md) - [Releases](https://github.com/AlbrechtL/welle.io/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/albrechtl-welle-io