Also known as: back-pressure, backpressure, flow control

Back-pressure is a flow-control strategy in which a stage that is falling behind pushes a signal upstream so its producer slows down, rather than letting an unbounded backlog pile up between them.¹ In a streaming DSP pipeline it is what keeps every buffer bounded: when the demodulator can only process so many samples per second, back-pressure ensures the source is throttled to that rate instead of the buffer overflowing into an overrun.

Demand flows upstream: the slow demod's inability to accept more data propagates back to throttle the source, so no buffer between them grows without bound.

How it works

The mechanism is a bounded buffer between each pair of stages. When the buffer fills, the producer can no longer deposit into it and must wait — that wait is the back-pressure. There are two common shapes:

• Blocking (implicit). The producer calls a push that simply blocks when the ring buffer is full, or writes to a bounded channel that parks the sender until a slot frees. No explicit message travels upstream; the buffer’s fullness is the signal, and the producer’s own thread stalls until the consumer catches up.
• Demand-based (explicit). The consumer announces how much it can accept — a credit or request count — and the producer sends no more than that. This is the model formalized by Reactive Streams, where a subscriber requests n items and the publisher is contractually forbidden from exceeding outstanding demand.²

Either way, the steady-state effect is the same: the whole chain runs at the rate of its slowest stage, and memory use stays bounded because nobody is allowed to get arbitrarily far ahead.

In practice

Back-pressure is the right tool when the source can be slowed — a file, a socket you can stop reading, or a synthetic generator. It cannot save you when the source is a free-running ADC: a live radio’s clock does not accept “slow down,” so an over-full pipeline there must drop samples (overrun) instead. This is the key distinction an SDR author has to keep straight. Back-pressure also interacts with latency: a deep buffer with back-pressure trades responsiveness for smoothness, while a shallow one throttles sooner but reacts faster. A pipeline that mixes real-time and non-real-time sources typically applies back-pressure everywhere except the live front end, and monitors that front end for drops.

Relevance to SDR

Block-based frameworks build back-pressure into their scheduler: a downstream block that stops consuming leaves its input buffer full, the upstream block’s output buffer then fills, and the scheduler simply does not run a block that has no room to write — demand propagates backward for free. When there is no hardware to set the pace, a deliberate throttle block is inserted so the flowgraph self-limits to real time instead of spinning as fast as the CPU allows.

GopherTrunk relies on this pattern when the source is throttleable. Its .cfile replay path reads from a file, so a slow decoder naturally back-pressures the reader — reads just proceed at the decode’s pace, which is why replay is deterministic and easy to test. Against a live radio, GT cannot back-pressure the ADC, so it instead sizes its buffers and counts drops, letting the overrun counter reveal when a consumer stage has fallen behind. Go’s bounded channels give the same blocking-producer semantics on the paths where GT does control the source.

Sources

1. Back pressure — Wikipedia, on back-pressure as a flow-control concept in pipelines and information systems. ↩

2. Reactive Streams — Reactive Streams specification, on demand-based (request-n) back-pressure between publishers and subscribers. ↩

See also

• Block scheduler
• Sample buffer
• Throttle
• Ring buffer
• Overruns & underruns
• Real-time DSP