[nullc]

> 24/192 is also great for digital synthesizers--if you're generating a waveform like a sawtooth that has theoretically instantaneous transitions, they can eat as much frequency as you can give them.

So if your synthesizers do not use proper band-limited oscillators then 192KHz is _FAR_ too slow. You'd want to be running at hundreds of KHz, perhaps a few MHz.

In reality synth software that doesn't sound like crap uses band limited oscillators and should work okay at 48KHz too. That said, even if the oscillators are band limited it may be the case the varrious modulations aren't band limited properly, as getting those wrong won't sound instantly wrong (in particular because you have to modulate to make it wrong, and the underlying change of the modulation may make it harder to tell its wrong).

Though also in those cases if you're not counting on every step being properly band limited then 192KHz may be an improvement but you're still probably getting some meaningful aliasing. 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.

Maybe 192KHz really is enough to suppress the aliasing artifacts but I think to be convinced of that I'd want to see a system that supported both and validate that the difference between a downsampled 48KHz output from the two modes was below -90dB or something.

Or otherwise you can just declare that the aliasing is part of the sound and then there are no right choices... 24khz sampling, 48k, 192k ... who cares, use what you like best. :)

[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.