Native real-time audio engines meet audio deadlines but are hard to connect to machine-learning workflows, while tensor frameworks integrate with machine learning but process audio as offline batches without timing guarantees; runtime layers built on them inherit the host's scheduling and deployment footprint. This paper presents Fluxion, a Rust audio DSP runtime for cascaded second-order sections, FIR filters, and delay-line effects. Fluxion implements the parts that are specific to DSP: closed-form filter design, forward kernels, analytic adjoints for the recursion, and stability checks. It relies on existing libraries for the autodiff graph, GPU code generation (tested here on CUDA), and array interchange. One graph algebra is lowered to a differentiable training engine and to an allocation-free real-time engine; between them, a trained graph is checked for stability and frozen into a versioned artifact that an edge device checks again before playback. We compare Fluxion with six framework-hosted and native baselines under one float32 protocol. Among the systems that compute the exact recursion, Fluxion has the highest GPU throughput when data stays on the device and the highest throughput on most CPU workloads, while its CPU training step is slower than those of torchaudio and GRAFX. Its test suite checks the audio thread for allocations with an instrumented allocator, and we report measured latency tails. Fluxion is open source at https://github.com/matteospanio/fluxion.
Figures & tables
Framework
GPU
Portable GPU
Analytic ∇
Design-param ∇
Stability cert.
Real-time
RT verif.
Edge footprint
Ckpt import
Fluxion
✓
∼ (CUDA val.)
✓
✓
✓ (+ in-loop)
✓
✓
✓ ( O (MB))
✓ (FLAMO, TorchFX)
TorchFX [ 8 ]
✓
✗
∼ (opt-in)
∼
✗
∼ (CPU meas.)
✗
✗ ( O (GB))
✗
torchaudio [ 4 , 5 ]
✓
∼ (PyTorch)
∼ ( lfilter )
∼
✗
✗
✗
✗
✗
GRAFX [ 7 ]
✓
∼ (PyTorch)
∼
∼
✗
✗
✗
✗
✗
FLAMO/ADAC [ 9 , 10 ]
✓
∼ (PyTorch)
✗
✓
∼ (design)
∼ (FAUST exp.)
✗
∼
∼ (FLAMO → FAUST)
anira [ 21 ]
✗
—
✗
✗
✗
✓ (default +1 buf.)
∼ (sanitizer)
∼ ( O (100 MB))
✓ (ONNX/TS/TFLite)
TABLE I: Feature comparison. ✓ supported, ✗ not supported, ∼ partial. “Analytic ∇ ”: hand-derived adjoints instead of unrolling on the host tape. “Portable GPU”: not tied to one vendor, with validation status inline. “RT verif.”: audio path checked under allocator instrumentation. “Ckpt import”: reads filter checkpoints from other frameworks.
Fig. 2: Throughput on one workstation (RTX 3070 + i9). (a) Cross-system medians, with separate resident and one-shot GPU regimes. (b) One-shot decomposition at 67 Msamples, with device synchronisation between stages. With pinned staging, Fluxion’s transfers reach 6.4 GB/s and the kernel takes 23 ms; TorchFX has a slower kernel and a slower download to pageable memory.
System
CPU batch
CPU 8ch
CPU mono K8
GPU res.
GPU 1-shot
Fluxion
2603 (897)
1354 (288)
109 (108)
2990
635
TorchFX
1893 (364)
1202 (407)
63 (60)
1580
367
torchaudio
64 (20)
106 (32)
9 (8)
1468
373
GRAFX ( lfilter )
121 (36)
145 (55)
9 (8)
1321
359
GRAFX ( fsm ) †
30 (19)
21 (14)
5 (4)
1199
353
FLAMO †
—
102
14
8964
478
TABLE II: Cross-system throughput (Msamples/s, medians, float32; single thread in parentheses), co-run on the workstation of Sec. IV-A1 . Workloads: batch = 64 × 524k (3 sections), 8ch = 8 × 60 s (order 4), mono K8 = 1 × 60 s (order 16); GPU = 16384 × 4096 (67 Msamples, order 8), resident / one-shot (Fluxion: owned input buffer). † frequency-sampling approximation, not the exact recurrence; ∗ single-threaded library; FLAMO’s batch cell does not apply. Bold = best exact-recurrence system per column (multi-thread).
Fig. 3: Coloration inversion with a parametric EQ. (a) Training loss for the three parameterisations. (b) Magnitude response of the frozen artifact trained on design parameters, the file that the real-time engine plays.
K
T
Fluxion
TorchFX ddsp
torchaudio
GRAFX
FLAMO †
1
16k
11
10 / 15
4 / 7
3
3
1
64k
46
22 / 16
17 / 30
—
—
4
16k
26
38 / 63
15 / 26
13
5
4
64k
114
82 / 63
75 / 113
—
—
8
16k
48
73 / 126
31 / 52
26
5
8
64k
207
162 / 126
149 / 221
—
—
TABLE III: One training step (forward and backward, squared-error loss; ms, median) of a K -section cascade over a batch of 16 signals of T samples. Fluxion: analytic adjoints on the CPU, one signal at a time. TorchFX ddsp : analytic adjoints over the native kernel (CPU/CUDA). torchaudio lfilter : its built-in differentiable path (CPU/CUDA). GRAFX: autograd over its exact lfilter backend (CPU). FLAMO † : frequency-sampling step (magnitude-response MSE at nfft=T ), whose cost barely depends on K . An unrolled recurrence takes 408 ms at K=1,T=4 k, about 153 × the analytic path per sample.
Fig. 4: Per-block processing time (unpaced) at 128 and 512 samples. The violet curve is the same code on a Raspberry Pi 5; the orange point is TorchFX’s p99 from our earlier study.
Stack
On disk
Peak RSS
Wall
Fluxion CLI (x86-64, stripped)
3.2 MB
11 MB
20 ms
Fluxion CLI (Pi 5, aarch64)
2.8 MB
11 MB
46 ms
CPython + torch + torchfx (import only)
1.7 GB
625 MB
4.3 s
TABLE IV: Deployment footprint. The Fluxion rows process 10 s of audio (16th-order cascade and reverb, file to file) on the workstation and on a Raspberry Pi 5 (binary cross-compiled, zig-linked); the Python row is the cost of import torch, torchfx alone.
Fig. 5: The SoundFood soundlamp, a 7.1 smart speaker that plays AI-generated music matched to each dish in restaurants. Its equalisation and directional FIR chain runs in real time on a Raspberry Pi-class core (Sec. IV-C3 ).
Massachusetts Institute of Technology Cambridge, MA · Artificial Audio, Multimedia Communications and Signal Processing Friedrich-Alexander-Universität Erlangen-Nürnberg Erlangen, Germany