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 ).
Differentiable audio processors are habitually designed and optimised in machine-learning frameworks, but deploying them as real-time audio effects still often requires non-automatic implementation in a dedicated digital signal processing language. The translation is error-prone, demands an onerous verification process, and detaches research prototypes from usable production tools. That being so, we present ADAC, a compiler that lowers a trained model to a framework-agnostic intermediate representation and emits efficient FAUST code whose impulse response matches the source model to within floating-point arithmetic noise, direct paths included. The optimisation loop is made audible by replacing the model in a running plugin after each gradient step. The exported processor carries a small set of macro-controls that leave its stability intact. A stability certificate computed from the shipped parameters is checked before the plugin is built. At the demonstration, a feedback delay network is trained and exported to a working plugin.
Facundo Franchino, Sebastian J. Schlecht
Massachusetts Institute of Technology Cambridge, MA · Artificial Audio, Multimedia Communications and Signal Processing Friedrich-Alexander-Universität Erlangen-Nürnberg Erlangen, Germany
This is an implementation and measurement study of what it costs to run a streaming speech enhancer on a CPU. We port FastEnhancer-Medium at 48 kHz to faster-enhancer.c, a C runtime with six int8 GEMM tiers selected at initialization, leaving architecture and weights untouched. One Apple M2 core reaches 0.069 real-time factor, against 0.230 for the fp32 ONNX Runtime graph on the same machine, a 3.3x speedup. A Galaxy S23+ (Snapdragon 8 Gen 2) reaches 0.096. The speedup comes from specializing every layer of the runtime around one fixed model. Activation ranges are recomputed per frame, so no calibration set is needed; the k=3 convolutions use Winograd F(2,3); cross-stage state is fp16; the GRU and the dequantization epilogues are fused; and nothing is allocated after startup. Over 824 VoiceBank-DEMAND utterances the engine tracks fp32 to within -0.006 PESQ and -0.08 dB SNR. Speed alone does not settle deployment cost. The enhancer holds a fraction of a core for as long as the microphone is open, so its real-time factor is a duty cycle. A benchmark races through a file; an audio callback does not. Pacing to the 6.67 ms deadline costs 4.2x per frame, saves 49% of the energy, and leaves the cheapest core placement missing 96% of its deadlines. All SIMD tiers within an architecture family emit byte-identical output. The runtime is released as a dependency-free library.
Gyeongmin Kim
Department of Computer Science, Hanyang University, Seoul, Korea
Modern neural audio models run on accelerators whose peak throughput comes from dense matrix multiplication, increasingly at the edge and in datacenters. The conventional acoustic frontend, however -- a Short-Time Fourier Transform (STFT) followed by sparse Mel aggregation -- remains a multi-stage pipeline centered on the Fast Fourier Transform (FFT), with execution overheads unlike the dense linear algebra dominating the inference stack. This work introduces MelT, a portable single-stage Mel frontend that precomputes Mel-spaced Non-Uniform Discrete Fourier Transform (NDFT) bases and applies them to time-domain frames through General Matrix Multiplication (GEMM). The contribution is a computational design principle: decoupling Mel feature extraction from vendor-specific FFT primitives and lowering it onto the matrix-multiplication substrate accelerators already optimize. It is not a new spectral operator. MelT's direct projection performs more arithmetic than the FFT pipeline. Yet in the compact-resolution regime of neural audio frontends, it achieves a 1.64-times to 3.29-times latency reduction and up to a 3.03-times reduction in measured active energy, from the Apple A18 Pro to the NVIDIA H100. All gains are within-platform comparisons, accompanied by task-level validation. Word error rate stays statistically equivalent to the native frontend's on frozen Whisper models of medium size and larger; speaker-attribute classification on VoxCeleb1 is non-inferior. The cepstral extension MFCCT preserves utility on a clinical respiratory-insufficiency classification task (SPIRA) while improving on the MFCC baseline. These results indicate that, in practical regimes on the accelerators evaluated here, hardware alignment rather than arithmetic count can govern the realized cost of feature extraction.
Augusto Camargo, Marcelo Finger
Institute of Mathematics and Statistics (IME), University of São Paulo, São Paulo, Brazil