3 ms·

Splice type of synthesizer emulations, variants of convolution, physical modelling, filtering, oversampling and so on...

Dylan16807 8y ago
Synth 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 ago
  There 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 ago
    I 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 ago
      Now do this for 32 (or more) audio tracks simultaneously.
      - Dylan16807 8y ago
        You 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.
        merinowool 8y ago
        More cores are better, but you are limited by the slowest chain. So you can have 100 of cores, but if only one chain can't be computed for time duration of the buffer it will stutter. It is not uncommon to have like %15 utilisation on 16+ core cpu and having it stutter, because all cores are too slow to process the chain on time.

Dylan16807 8y ago

Synth 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 ago
There 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 ago
  I 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 ago
    Now do this for 32 (or more) audio tracks simultaneously.
    - Dylan16807 8y ago
      You 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.
      - merinowool 8y ago
        More cores are better, but you are limited by the slowest chain. So you can have 100 of cores, but if only one chain can't be computed for time duration of the buffer it will stutter. It is not uncommon to have like %15 utilisation on 16+ core cpu and having it stutter, because all cores are too slow to process the chain on time.