Also known as: processing latency, pipeline latency, buffer latency
DSP latency is the elapsed time between a sample arriving at the input of a digital-signal-processing chain and the corresponding processed sample leaving the output.1 In a software-defined radio it is the lag between antenna-borne energy being captured and a decoded symbol, audio sample, or detection appearing downstream. It is distinct from throughput: a chain can sustain a very high sample rate yet still hold each sample for a long time before releasing it.
How it works
Latency in a DSP chain comes from three sources that add together.
- Block / buffer size. Software rarely processes one sample at a time; it works on blocks (frames) held in a sample buffer. A stage that consumes 4096 samples per call cannot emit anything until that block is full, so it imposes at least one block-time of delay — 4096 samples at 48 kHz is about 85 ms. Larger blocks amortise per-call overhead and vectorise better (higher throughput) but push latency up. This is the central throughput-versus-latency trade.
- Algorithmic / group delay. Filters and framing introduce their own delay. A linear-phase FIR of length N delays the signal by (N−1)/2 samples; a symbol-framer must collect a whole frame before it can be validated. This is intrinsic to the maths, not the implementation.
- Queueing. Between stages, ring buffers and thread hand-offs hold samples waiting for the next worker. Under load these queues fill, and standing queue depth becomes latency; if they overflow you get overruns instead.
Total end-to-end latency is roughly the sum of every stage’s block delay plus its group delay plus mean queue occupancy. Halving latency usually means smaller blocks, fewer stages, or shorter filters — each of which costs throughput headroom or filter quality.
In practice
The engineering question is always how much latency is acceptable, because reducing it is never free. Interactive or closed-loop applications — a transceiver’s TX/RX turnaround, a feedback control loop, live voice — need latency in the low tens of milliseconds and pay for it with small blocks and tight scheduling. Batch or monitoring applications — spectrum logging, offline replay, a scanner that only has to keep up — can use large blocks, deep queues, and long filters, trading hundreds of milliseconds of delay for efficiency and robustness against scheduling jitter. Choosing block size is therefore one of the first architectural decisions in an SDR program, and it ripples through buffer sizing, thread count, and how much slack the block scheduler has before it underflows.
Relevance to SDR
Every SDR receiver is a latency budget. Samples cross the USB or network link in bursts, sit in a driver buffer, get down-converted and filtered, then framed and decoded — each step a contribution. A trunking scanner like GopherTrunk is latency-tolerant but throughput-critical: what matters is that the real-time DSP chain keeps pace with the control channel so no bursts are dropped, while an extra hundred milliseconds before a talkgroup’s audio starts is imperceptible to a listener. So GopherTrunk favours block sizes large enough to process the control-channel and voice streams efficiently and to absorb host scheduling jitter, accepting the modest added delay. A latency-sensitive application — a repeater controller, a phase-locked ranging system, a two-way voice link — would make the opposite call, shrinking blocks to trim the delay even at the cost of CPU efficiency. The point applies to any SDR software: latency and throughput are separate axes, and the block size that sets them is a design choice, not a default to leave unexamined.
Sources
-
Latency (audio) — Wikipedia, on buffering delay in real-time audio/DSP pipelines and the role of block size. ↩