[Archit3ch]

> I think given how fast computers have become relative to digital audio there is probably a good case to just make any "modular synth" run at 32-bit 480KHz or even 4.8MHz through every stage that could process the audio.

1. It should run at FP64 if you want to preserve filter resonances, etc.

2. At 10x/100x fixed-rate oversampling, even a modern "fast" CPU will have very few cycles per (higher-rate) sample to run the DSP for 1 "module" of the software modular. Forget about interconnected modules, multiple tracks, or polyphony. For this kind of "analog"-style processing, it's better to run adaptive-rate algorithms (think SPICE) instead of wasting compute on unnecessary extra audio samples.

[nullc]

so an 8-core zen4 should be able to sustain more than 300 gflops of 64-bit multiply-adds. At 480khz that's 625k operations per sample. I'll grant the 100x oversampling was probably too ambitious. :P

For adaptive rate I think the issue there is you have a hard-realtime constraint for this usage (even if you wouldn't mind rendering offline, you kinda have to hear it realtime to tweak it-- after all you might tweak it in a way that brings out an artifact you like and then be disappointed by the render). Also in the case of a whole modular system having all sorts of different parts needing to be part of the adaptation loop seems pretty hard to me.

My thinking was just in general that 192k is really not enough to prevent aliasy algorithms from messing up. If you are alias safe you can probably run at 48k and be fine. If you're not, you really want to go much higher.

[Archit3ch]

I'm travelling without my Zen 4 machine, or I could test it. ;) Oh well, Compiler Explorer is enough to look at these microbenchmarks on your own.

These simulations are single core to avoid core-to-core latency. Number of cores isn't relevant unless you want to run independent voices/channels and sum them at the end.

So you start with a very optimistic ~90 GFLOPs of 64-bit FMA on Zen 4. Unfortunately, not all operations are clean multiply-adds. Realistically, you'll need trigonometric functions and LUTs, which are quite slower. Btw, the tradeoff between when to compute vs LUT is very fragile and can change due to a ton of factors (notably integrator algorithm).

Then the data you are operating on won't fit cleanly in AVX-512 registers, requiring spills to L1 cache. Ok, still fast on a modern core.

Of course, the peak theoretical number assumes clean vectorization with double-pumped AVX-512... which also won't happen in practice. Classical DSP will fare better (https://www.youtube.com/watch?v=Ssq0a-YdamM) but SPICE integrators are inherently branchy and divergent. Especially for adaptive integrators, you'll waste a lot of operations trying to "lock in" at the exact time point where the waveform turns a corner. Apple Silicon is better at this messy, branchy code.

So yeah, it's possible-but-hard to hit hard-realtime under these conditions.