How many Cpu cores can ardour use
As many as you have – see preferences > General > DSP CPU Utilization
So if I had a 64 core cpu it would be able to use them all.
Yes Ardour is capable of that as far as I know, but whether your session will be able to actually utilize that is something else. It’s not quite as simple
If it’s used for film and other large projects then ya it would be nice to have
If dealing with a large session you will likely benefit from many cores yes.
The parallelism relies on you having as many (or more) tracks as you do CPU cores. They also need to be independent (i.e. Track 1 does not feed Track 2). Under those circumstances (which are quite typical), you would get full utilization.
However, note that Ardour sessions with 100+ tracks run relatively easily on a 4 core system unless all the tracks are heavily burdened by CPU intensive DSP (like Reverbs and certain kinds of EQ), or digital synthesis.
I have a question about keeping tracks “independent” to maximize CPU load distribution between cores. I am running a CPU-heavy synth in Reaktor which only operates with single cores, so I’m trying to load multiple instances of the synth on different tracks to take advantage of Ardour’s multicore support.
Here’s a basic breakdown of my routing:
Mono Audio Track #1: Input 1 from audio interface (no plugins)
---
MIDI Channel #1: Reaktor instrument instance #1
-has side chain audio input from Audio Track #1
Stereo Audio Track #2: Input from Reaktor instrument instance #1 Channels 1+2
Stereo Audio Track #3: Input from Reaktor instrument instance #1 Channels 3+4
---
MIDI Channel #2: Reaktor instrument instance #2
-has side chain audio input from Audio Track #1
Stereo Audio Track #4: Input from Reaktor instrument instance #2 Channels 1+2
Stereo Audio Track #5: Input from Reaktor instrument instance #2 Channels 3+4
So, with this arrangement would MIDI #1, Audio #2 and Audio #3 be on one core, and then MIDI #2, Audio #4 and Audio #5 be on another?
Or is the fact that MIDI #1 and MIDI #2 both have a sidechain input from Audio #1 bump them onto the same core?
Just trying to figure out the most efficient way to minimize CPU load. Thanks!
With the setup you describe the two Reaktor instances are scheduled to be processed in parallel, as are the 4 stereo outputs (they may or may not run on different cores).
Yet the question is, does Reaktor’s load vary depending on the data it receives? If not, you run two instances for no actual benefit, yet still have synchronization overhead.
I had a suspicion that would be the case with the sidechain. OK, there’s another way I could configure it using Reaktor as an FX rather than an instrument:
Stereo Audio Track #1: Input 1 from audio interface
-Reaktor FX Instance #1 as a plugin
Stereo Audio Track #2: Input from Audio Track #1 post fader
Stereo Audio Track #3: Input from Audio Track #1 pre fader (send?)
---
Stereo Audio Track #4: Input 1 from audio interface
-Reaktor FX Instance #2 as a plugin
Stereo Audio Track #5: Input from Audio Track #4 post fader
Stereo Audio Track #6: Input from Audio Track #4 pre fader (send?)
In this case, the only thing linking them is that both Audio #1 and Audio #4 use the same input from my audio interface, but are otherwise share no routings. Would that keep them independent?
And thanks for your reply!
I don’t understand, what suspicion is that?
The two reactor instances run in parallel (after all sources feeding them are processed).
Ah, sorry, I misread you. So, you’re saying that in my original routing they would in fact be processed on separate cores, but the question is will each instance of Reaktor be working more/less than the other, because if they work as equally hard, it’s the still same amount of work overall. (Hope I’m phrasing that properly, ha, admittedly at the limits of my knowledge here)
In my particular scenario, I think there would be a difference between the instances. I’m using the input to feed a granular sampler. How much processing power each instance of the sampler is consuming varies depending on how many grains I’m generating after I’ve done the sample.
For the bigger context, I programmed a patch in Reaktor that had 3 granular samplers and it was running on a single channel of Ardour. I was definitely starting to max out the processor. So, I was reading about Reaktor being only able to use a single core and some people suggested that breaking up a patch between multiple instances on separate channels in a DAW that does have multicore support might be a way to eek out a bit more processing power. So, I’ve rewritten the patch in Reaktor to only have a single granular sampler, and then loaded separate instances of it on three different tracks as described above.
I had to run to work, so I didn’t get a chance to finish setting it all up to see if it performed better or not. I was just wondering if routing it with a sidechain negated the benefits. But I know understand from your response that at least in theory it shouldn’t.
This is the only part I’m not following. Synchronization of what excatly? 
Ardour schedules them to run in parallel, but Ardour itself does not pin the process threads to dedicated cores. The OS scheduler usually does a better job to distribute the load on modern CPUs.
As for synchronization overhead: say one Reaktor instances completes processing earlier than the other, master bus will have to wait, and only run when when both are complete. But forget that I’ve mentioned that, it isn’t really significant.
Anyway, just check the DSP load (status bar top-right) and measure it.
For posterity and those that are curious, the results are night and day, here are the DSP percentages from both inside Reaktor and Ardour:
3 Samplers in 1 patch on 1 track:
Reaktor: 65%
Ardour: 67%
1 Sampler in 3 separate patches on 3 separate tracks:
Reaktor 1: 16%
Reaktor 2: 13%
Reaktor 3: 12%
Ardour: 33%
So, interestingly, the Reaktor DSP load does vary between instance depending on how hard it’s working.
Now to figure out how to have all three Reaktor plugin windows open at the same time without a ton of clutter, but I’ll take that over the DSP load any day.
Exciting stuff!
3 Likes