I keep running into this.
In the Settings I set to use All processors except 1 and also set the priority to be the highest.
Ardour/Mixbus runs on a rackserver with 32 real processors and 256G Memory.
However, having all these processors and huge memory at its disposal, Ardour still has the same DSP bottleneck.
Am I lead to believe that the DSP is single instance and not parallelized ?
If so, what is the use of the multiprocessor support ?
Is that for plugins only.
Would really be great if the DSP can be parallelized, and will increase the operating headroom substantially.
The DSP is parallelized at the track level. If you have a track with “too much” DSP in it for one your processors to complete the work within the time represented by one buffer, there’s nothing we can do about that.
In case of Mixbus, in a each process cycle first all tracks run in parallel (up to the number of available/configured cores), then all Mixbusses (up to all 12 in parallel), and then finally the master bus is processed.
In pretty much any modern machine CPU is not the bottleneck that limits DSP.
And to give a little more context, it is important to note that DSP is NOT a measure of CPU usage though there can be some relationship between the two. DSP percentage is effectively how much time was taken in each processing cycle compared to the total amount of time allowed by the buffer in use. Thus the larger the buffer the lower the DSP even if CPU load hasn’t really changed.
But otherwise exactly as @paul and @x42 state above.
Ok I understand now. Your definition of DSP % is what threw me off and made it not understandable.
Since DSP use is defined per track per cycle, it explains why I get no change in DSP use as I increase cores. My tests were always done with a few tracks, so I would not run out of processors, and explains why the DSP use remained the same never mind the amount of processors added.
I assumed that a DSP process would be parallelized, which is not the case.
You rather run multiple instances, a processor per track.
It should be able to parallelize the DSP code used per instance for a channel. Why is this seemingly difficult ?
Understandably the benefits will diminish as you approach the case when; number of tracks equal to number of processors, but it should help in the case of much less tracks than processors and higher sampling rates.
Question:
What is the relationship between processor speed and single instance DSP use in Ardour?
Linear ?
It is parallelized. e.g all Mixbus Track EQs run in parallel.
but inside a single track you have e.g.
input → gate → EQ → compressor → output
Those units have to run in sequence. The EQ’s input depends on the output of the gate. The CPU cannot run the EQ, before the gate has produced output.
It is not parallelized per instance, where instance would be one track, that is what I referred to in my last question.
The question is why the DSP code in the instance cannot be parallelized.
There is no reason why not.
So what you are saying is that within a track there is absolutely no parallel process in the code or parts that can be parallelized within a cycle? That is hard to believe. But if you say so, I must believe you as you have insight in the code.
I could always manage to find a way to break code up into parallel processes. Wherever Fourier series or Convolution/Deconvolution was used I always found a way to substantially parallelize it and I am pretty sure e.g. the filter section of the code uses either one or a combination of the two.
Let’s say you have 3 plugins on a track. You can’t run the 2nd plugin till the first one has finished processing its input, because the 2nd plugin is going to operate on the output of the first plugin. Ditto for the 3rd plugin, which requires the 2nd plugin to have finished first.
This is why there is no parallelism possible within a track - the signal flow path is sequential/serial.
You also cannot split by channel, because any stereo plugin needs to be a single instance operating on both channels together, not 2 instances of the plugin operating on left or right in parallel.
Yes, plugins may use threads internally to parallelize their own processing, but that’s no business of ours.
Filters almost never use FFT. That is way to expensive processing wise, and also introduces latency.
Most DSP does use SIMD which is why using larger buffersizes helps to lower the load.
Parallel processing in this case would have to happen inside a 3rd party plugin, and that may interfere with host scheduling. Furthermore thread synchronization adds overhead. Especially when processing small chunks (here msec) it is often counterproductive to parallelize tasks.
So, perhaps for retnev’s sake, who seems to understand a bit about operations, would we say that this is like atomic, transactional processing? You’re doing some database transaction, it’s got to be done in order x-y-z, and it’s locked down until it’s done (although, I would assume in Ardour there are no roll-backs )?
@x42 and @paul could you introduce all this valuable info you provided here into Ardour’s manual, which currently just says:
“DSP: for Digital Sound Processing, shows how much of the CPU is used by Ardour and its plugins”
“DSP CPU Utilization, Signal processing uses: sets how many cpu processors can be used to do signal processing. It can be set to use one up to all processors.”
)?