5 ms·
Audio production. It is difficult if not impossible to parallelise one channel workload as each plugin depends on results of previous one.
by merinowool 8y ago
Audio production. It is difficult if not impossible to parallelise one channel workload as each plugin depends on results of previous one.
- majewsky 8y agoIf the plugins are chained together in a pipeline, that's actually trivial to parallelize: Each plugin runs on its own core/hyperthread, with small ring buffers between them to pass data along the pipeline.
- merinowool 8y agoBut to process one plugin it still takes x amount of time and once cumulative x is longer than time of the audio buffer you'll get drop outs. That's why single core performance is the most important factor.
- majewsky 8y agoAh, you mean realtime? Yeah, then your concerns are right.
- Dylan16807 8y agoWhat kind of workloads require more than ten thousand instructions per sample?
- merinowool 8y agoSplice type of synthesizer emulations, variants of convolution, physical modelling, filtering, oversampling and so on...
- Dylan16807 8y agoSynth emulation sounds like it can take a fractional-millisecond hit to run buffered on a different core. "variants of convolution" is hopelessly vague. Physical modeling can't be parallelized? Filtering I'm not an expert on but that's exactly where I'd expect a few instructions to go very far. Oversampling I already took into account when saying "ten thousand". This is not to say that your problems aren't real. But I'm skeptical a concerted effort was ever made to go multi-core here. What's an acceptable level of total latency, so I can understand better?
- merinowool 8y agoThere are plugins that run their processing in parallel, but still they depend on results from the previous one in the chain. So there is only x number of plugins you can run in a channel, regardless how they process samples internally. Acceptable latency would be between 2 to 25ms, but typically it is 5ms to work comfortable. My projects stutter on 25ms latency on Ryzen 1800x.
- Dylan16807 8y agoI completely blame the OS and/or software here, not the chip. Let me put it this way: Take a sample rate of 200kHz. Take a pipeline with 12 steps that each require 2-3GHz. These cores can easily synchronize to within a fraction of a microsecond, so round up to 1us. Assume each plugin needs 10 samples available, and that the input-to-output latency might get as high as 20 samples when it's running on a completely dedicated core. So put a buffer between each core of 20 samples, plus an extra 50% to be conservative, plus an extra 15us=3 samples to synchronize the cores with very conservative slop. So 33 samples per buffer. 12 inter-core buffers now take up a total of 396 samples, or slightly under 2ms. For a pipeline doing ~30GHz of work. Nothing about modern multi-core CPU design makes a pipeline like this difficult. It's all software considerations, where the use of soft-realtime threads 'should' be straightforward, while letting the OS use the spare cores. If you have a stutter at 25ms then someone blatantly screwed up their code.
- TylerE 8y agoNow do this for 32 (or more) audio tracks simultaneously.
- Dylan16807 8y agoYou sound like you're disagreeing? If so I think you lost track of what this discussion was about. I'm arguing that in audio processing, if the software is well-written, more cores can crush the performance of a single fast core. Even if it's a very serial pipeline. Now you're here, describing an audio processing scenario where it's trivial to split the load up over many cores and run 10x faster or more. I agree, more cores are better...? If you're just arguing that you can't dedicate 12 cores per track while also having 32 tracks... that's certainly true, but completely irrelevant? Completely accurate that the multi-core CPU is not 300 times faster than a single fast core. But nobody said it was.