Also known as: VOLK, Vector-Optimized Library of Kernels
VOLK — the Vector-Optimized Library of Kernels — is a library of hand-tuned, SIMD-accelerated math routines for software-defined-radio DSP, together with a dispatcher that selects the fastest available implementation for the CPU it is running on.1 It grew out of the GNU Radio project to solve a specific problem: the inner loops of a radio — multiply-accumulate, magnitude, phase, format conversion — run billions of times, and writing them once per instruction set is both tedious and brittle. VOLK centralizes those kernels so every application shares one optimized, portable copy.
How it works
VOLK is organized around kernels: named vector operations such as “multiply two complex float arrays,” “compute the magnitude of a complex vector,” or “convert 16-bit integers to floats.” Each kernel ships with several protokernels — independent implementations of the same math targeting different instruction sets: a portable generic C version plus tuned variants for SSE, AVX/AVX2/AVX-512 on x86 and NEON on ARM. The public API is a plain C function per kernel; the caller never sees the variants.
Selection happens by CPU-feature detection. At load time VOLK reads the processor’s capability
flags and binds each kernel’s function pointer to the best protokernel the machine actually
supports, so a binary compiled once runs the AVX path on a modern desktop and falls back to
NEON or generic C elsewhere — no recompilation, no #ifdef maze in the caller. To resolve ties
where several variants are viable, the volk_profile tool benchmarks every protokernel on the
real hardware and writes a small config file recording the empirically fastest choice per kernel.
Two implementation details make VOLK effective in practice:
- Alignment awareness — each kernel provides aligned and unaligned entry points, because SIMD loads are fastest when data sits on 16- or 32-byte boundaries; VOLK exposes an aligned allocator so callers can get that speed.
- Correctness harness — a QA suite checks every protokernel against the generic reference so the AVX and NEON paths produce the same numbers, which matters when a decoder’s bit decisions depend on them.
Relevance to SDR
VOLK is the numerical engine under a great deal of open SDR software. Inside GNU Radio, the hot loops of FIR filters, the frequency-translating filter, magnitude and AGC blocks, and sample-format converters call VOLK, which is a large part of why GNU Radio sustains high sample rates on commodity CPUs. Because it is a standalone C library, projects outside GNU Radio link it directly to accelerate their own FIR filters, correlators, and FFT front ends. It is, in effect, the community’s shared answer to “make this DSP inner loop fast on whatever CPU the user has,” a concern it shares with math-heavy libraries like liquid-dsp.
GopherTrunk does not use VOLK. GopherTrunk is written in Go, not C, and its DSP inner loops are Go code that leans on the Go compiler and, where it matters, on Go’s own facilities rather than a C SIMD library — keeping the project a single dependency-free static binary. VOLK is still directly relevant as the reference model for the problem GopherTrunk must also solve: SIMD-friendly, cache-aware, run-time-portable inner loops. Where GNU Radio reaches for VOLK, GopherTrunk relies on careful Go and rate-invariant design to keep real-time decoding within budget on the same commodity hardware.
Sources
-
libvolk.org — the VOLK project site and documentation, describing kernels and protokernels, run-time CPU dispatch,
volk_profile, aligned allocation, and the QA harness. ↩