Thank you to Matthew Delashaw, who has written in and shared a guest post with us. Matthew has rewritten the 2013 librtlsdr library from the ground up in Rust. His motivations for doing so and the results are explained in the post below:

I actually started down this path as an "interest". There was a Ham radio Technical Interest Group I was planning on attending a meeting. I had already wanted to convert my Raspberry Pi into a fallback radio receiver for potential internet outages and listening to storm chasers on SKYWARN. Now I have the "v4" dongle, and a full end-to-end SDR solution. !Spoilers, I'm releasing a native smart phone client soon.

The RTL2832U chipset has powered affordable software-defined radio for over a decade. The reference driver, librtlsdr, was written in C around 2013 and follows the same architectural pattern it always has: a blocking callback loop, manual buffer management, and a programming model that predates modern async runtimes by years.

rtlsdr-next is a ground-up Rust rewrite. It exposes SDR data as a native Tokio Stream, ships a zero-allocation DSP pipeline, and has first-class support for the RTL-SDR Blog V4 — a newer hardware variant the upstream driver handles correctly but never cleanly abstracted. The result is faster, safer, and substantially easier to build applications on top of.

1.49 GiB/s IQ conversion on Pi 5  ·  ~45ms frequency switching (was ~270ms with 20 I2C toggles)  ·  0 allocations in the streaming hot path

Why rewrite it at all?

The C driver works. Millions of people run it daily via OpenWebRX, GQRX, SDR++, and friends. But its architecture creates friction at every layer: the callback-based stream makes backpressure impossible to reason about, the I2C bus is hammered with redundant open/close cycles, and the conversion routine uses a 256-entry lookup table whose cache pressure eats into throughput on modern out-of-order cores.

More practically: trying to integrate librtlsdr into a modern async Rust application means spawning a dedicated thread, wrapping callbacks in channels, and handling all the lifetime gymnastics manually. For every project that does this, someone reinvents the same boilerplate. There are plenty of Rust "wrappers" out there That exemplifies this.

The stream architecture

The primary interface is a standard async stream. A SampleStream wraps a background USB reader thread that feeds raw IQ bytes into a tokio::mpsc channel. The F32Stream layer sits on top and handles conversion, decimation, DC removal, and AGC — all in a single pipeline with no intermediate heap allocations.

let mut stream = driver.stream_f32(8)   // ÷8 → 256 kSPS
    .with_dc_removal(0.01)
    .with_agc(1.0, 0.01, 0.01);

while let Some(Ok(iq)) = stream.next().await {
    // interleaved f32 I/Q, ready to demodulate
}

The blocking USB read thread never touches the async runtime. Sample delivery to async consumers happens entirely through the channel, and the PooledBuffer type ensures the backing buffers are returned to the pool via Drop — no explicit lifecycle management needed at the call site.

• SampleStream — Blocking USB thread → tokio::mpsc channel. Pre-allocated buffer pool. Flush-on-tune via broadcast::Sender.
• F32Stream — Convert → decimate (FIR) → DC remove → AGC. Processes split I/Q in-place. No per-block allocation.
• PooledBuffer — Returns buffer to pool on Drop. try_send with blocking fallback thread — the pool never silently starves.
• BoardOrchestrator — V4Orchestrator / GenericOrchestrator produce a TuningPlan. Board logic never leaks into chip drivers.

The I2C repeater optimization

Every register write to the R828D tuner chip goes through an I2C bridge in the RTL2832U. The bridge must be explicitly opened and closed around each transaction. In a naive implementation — which is what the reference driver does — every call to set_frequency independently opens and closes the repeater for each register write.

A full frequency switch involves setting the PLL, MUX, filter coefficients, and various control registers. That adds up to roughly 20 open/close cycles, and each one costs ~13ms of USB round-trip time.

The fix: a single with_repeater(|| { ... }) closure that holds the bridge open for the entire mux + PLL sequence. One open, one close, all the work done in between.

// Before: ~20 repeater toggles ≈ 270ms
self.set_mux(hz)?;   // 10 writes, each with open/close
self.set_pll(hz)?;   // 10 writes, each with open/close

// After: 1 repeater toggle ≈ 45ms
self.with_repeater(|| {
    self.set_mux_raw(hz)?;
    self.set_pll_raw(hz)?;
    Ok(())
})?;

The distinction between write_reg_mask (opens and closes the repeater itself) and write_reg_mask_raw (no repeater toggle, must be inside a bracket) is enforced by convention throughout the codebase. Any raw variant called outside a bracket is a bug that surfaces immediately as a timeout rather than silently returning stale data.

Converter throughput

librtlsdr converts raw IQ bytes to float via a static 256-entry lookup table. It is a reasonable approach from an era when float math was expensive and cache was plentiful. On the Cortex-A76 inside the Pi 5, the situation is inverted: the NEON FPU is underutilized and random-access table reads create cache pressure that limits throughput.

The arithmetic equivalent — (x as f32 - 127.5) / 127.5 — is computed in two instructions per sample and is trivially auto-vectorized by LLVM. The compiler emits NEON FMLA instructions without any manual intrinsics.

The V4 inversion case is a particularly notable optimization. librtlsdr implements it as a two-pass operation: first a full LUT conversion, then a second pass to negate every Q sample. The Rust implementation folds both into a single pass, processing I and Q pairs together and avoiding a complete re-read of the output buffer.

RTL-SDR Blog V4 specifics

The V4 is a substantial hardware revision. It ships with an R828D tuner (not R820T), adds an HF upconverter and a GPIO-switched triplexer, and has several initialization quirks that librtlsdr discovered through usbmon traces and EEPROM string detection.

The board logic is isolated entirely in V4Orchestrator. Given a target frequency, it returns a TuningPlan — the actual tuner frequency, whether spectral inversion is needed, which triplexer path to select, and whether the frequency falls inside a notch band. The R828D chip driver never touches a GPIO.

Notable quirks baked into the driver: the R828D responds at I2C address 0x74 rather than the R820T's 0x34; frequencies below 28.8 MHz are upconverted by adding the crystal frequency, and the resulting spectrum is inverted (Q = –Q). Every demodulator register write must be followed by a dummy read of page 0x0a register 0x01 — the hardware requires this as a flush sync, and omitting it causes subsequent control transfers to stall with a pipe error.

Built-in DSP pipeline

The dsp module ships a complete demodulation stack. The decimator uses a windowed-sinc FIR with NEON acceleration on aarch64, with a scalar fallback that LLVM auto-vectorizes on x86_64. The FM demodulator is a quadrature discriminator with configurable de-emphasis. AM uses a two-stage DC-subtraction envelope detector. SSB uses the phasing method with a 65-tap Hilbert transformer windowed with Blackman-Harris for high sideband rejection.

All demodulators maintain state across block boundaries — the history overlap buffer in the decimator ensures the FIR convolution is correct at every chunk edge, which is essential for continuous streaming.

Standalone servers

Two installable binaries ship alongside the library. rtl_tcp implements the standard RTL-TCP protocol and is compatible with OpenWebRX+, GQRX, and SDR++. websdr is a self-contained WebSocket SDR server with a full spectrum and waterfall UI embedded as a compiled-in HTML file — no separate web server needed. Both support TLS. The WebSDR binary accepts --cert and --key flags for wss:// connections, which are required by iOS App Transport Security when using a public domain.

• OpenWebRX+ — confirmed working
• GQRX — confirmed working
• SDR++ — confirmed working
• Corona SDR (iOS) — confirmed working

Getting started

cargo install rtlsdr-next

# Smoke test — run this first
RUST_LOG=info cargo run --release --example hw_probe

# Start an rtl_tcp server
rtl_tcp --address 0.0.0.0 --port 1234

# Start the WebSDR UI
websdr --address 0.0.0.0 --port 8080

On Linux, set up a udev rule for persistent USB access without sudo. On Windows, Zadig is required to swap the DVB-T driver to WinUSB — build works without it, but the USB runtime requires it at runtime.

Source on GitHub at github.com/mattdelashaw/rtlsdr-next. Licensed Apache 2.0. Benchmarks measured on Raspberry Pi 5 (aarch64) and AMD Ryzen 7600X (x86_64) with cargo build --release, no target-cpu=native.

Keep and eye out for the smart phone app release here: Spectral Bands