RTL-SDR Next: Bringing Software Defined Radio into the Modern Async Era with Rust

For over a decade, the librtlsdr C library has been the bedrock of the SDR community. It is the “old gold” of the hobby—reliable, ubiquitous, but fundamentally anchored in the coding patterns of 2013. As hardware has evolved, particularly with the release of the Raspberry Pi 5 and the RTL-SDR Blog V4, the gap between what the hardware can do and what the legacy drivers provide has widened.

Enter rtlsdr-next: a high-performance, asynchronous, and safety-first Rust implementation designed to bring the RTL2832U into the modern era.

Why Rewriting “Solved” Tech Matters

#

You might ask: “If the C driver works, why rewrite it?” The answer lies in concurrency and performance bottlenecks.

Legacy drivers often rely on a callback-based model that can be difficult to integrate into modern async runtimes like Tokio. Furthermore, many of the performance optimizations in the original C code (like the 256-entry lookup table for U8 to F32 conversion) were designed for CPUs with very small caches. On modern out-of-order CPUs like the Cortex-A76 (Pi 5), these lookup tables actually introduce cache latency due to table fetches.

rtlsdr-next replaces these LUTs with instruction-parallel arithmetic. By performing direct (u8 - 127.5) / 127.5 conversions, the CPU’s scalar floating-point pipeline saturates the memory bus before the ALU even breaks a sweat, achieving throughputs of 1.49 GiB/s on a Pi 5.

Native Support for the Blog V4: The Orchestrator Pattern

#

The RTL-SDR Blog V4 isn’t just a generic dongle; it’s a sophisticated piece of hardware with a built-in HF upconverter and a triplexer. Driving it correctly requires a specific dance of GPIO toggles and I2C commands.

In rtlsdr-next, we use the BoardOrchestrator pattern to cleanly separate tuner-chip logic (R828D) from board-level logic:

• HF Upconversion: Handling the 28.8 MHz offset and mandatory spectral inversion (inverting Q) in hardware via the 0x15 demodulator register.
• Triplexer Switching: Toggling GPIO 5 to switch between the HF (Low), VHF, and UHF (High) input paths.
• I2C Resiliency: Chunking I2C writes to 7 data bytes to prevent the RTL2832U buffer from overflowing and stalling the USB pipe—a common cause of “Pipe Error” in legacy drivers.
• Register Sync: Every demodulator write is followed by a dummy read of page 0x0a, reg 0x01 to ensure the hardware state machine is flushed and synced.

The Multi-Client Daemon: One Dongle, Many Apps

#

One of the most frustrating aspects of SDR work is that the USB device is usually “locked” by a single process. If you want to run rtl_tcp for SDR++ and a WebSDR server for your browser simultaneously, you’re out of luck.

The rtlsdr-daemon in this project solves this. It acts as a hardware orchestrator that:

1. Claims the USB handle once.
2. Runs a zero-allocation broadcast pump using custom buffer pooling.
3. Spawns independent “Virtual VFOs” for every client.

Using Digital Down-Conversion (DDC) and per-client Numerically Controlled Oscillators (NCO), a dozen browser clients can tune to different frequencies within the 1.536 MHz hardware window simultaneously. The NCO uses f64 precision for phase accumulation to prevent long-term drift (~0.3°/sec error if f32 was used), ensuring crystal-clear audio even over long monitoring sessions.

Performance Benchmarks (ARM64)

#

Under the Hood: NEON SIMD Acceleration

#

For the decimating FIR filters, we’ve implemented a high-performance NEON SIMD path for aarch64. Using ARM intrinsics like vld1q_f32 and vmlaq_f32, we process taps in 4-wide groups, achieving a massive speedup over scalar convolution:

// ── 4-wide FMA loop (aarch64 NEON) ──────────────────────────────
while j < taps_simd {
    unsafe {
        let v_s = vld1q_f32(win_ptr.add(j));
        let v_t = vld1q_f32(taps_ptr.add(j));
        v_acc = vmlaq_f32(v_acc, v_s, v_t);
    }
    j += 4;
}

Getting Involved

#

The project is now stable and looking for hardware testers. Whether you’re running a Pi 5 at a remote site or just want a snappier GQRX experience on your laptop, give rtlsdr-next a spin.

Check out the source on GitHub: mattdelashaw/rtlsdr-next