Duel Core Support Question

[DrXparaMental]

Hi
This is my first post here and I am not really certain that I am asking this question in the right place or not. Here goes:

I am using Ableton's 5.2.2 to support VSTs & general recording. I see via Ableton's advertisements that the 6.0 version "supports duel core technology" Does that mean my current version does not? I tried asking this question on the Ableton Forums and it has gone unanswered.

Do in fact most software VSTs such as Stylus RMX support Duel Core technology? Thanks for baring with my ignorance.

Jeff

[DrXparaMental]

Hi (again)
Got this answered somewhat. 5.2.2 runs on a duel core machine but only uses one of the two cores. 6.0 fully supports the even distribution of processor labor among both. According to what I was told elsewhere, VSTs are not effected either way by single or duel core implication. I find this tough to believe though because no matter how you slice it, less CPU is less CPU.


Thanks,
Jeff

[Richard Berg]

According to what I was told elsewhere, VSTs are not effected either way by single or duel core implication. I find this tough to believe though because no matter how you slice it, less CPU is less CPU.

I'm not sure exactly what you were told, but it sounds right to me. A VST plugin can't control which thread processReplacing () is called from. And the host can't control what the plugin does once it receives control (apart from threading its own routines beforehand). The SDK guidelines encourage the developer not to hold locks and other expensive objects on the caller thread, but the host can't do anything about it.

Of course, a plugin can spin off its own threads. While the API is not explicitly designed around multiprocessing, a plugin author is free to optimize for dual core within its contraints.

[DrXparaMental]

I'm not sure exactly what you were told, but it sounds right to me. A VST plug in can't control which thread processReplacing () is called from. And the host can't control what the plugin does once it receives control (apart from threading its own routines beforehand). The SDK guidelines encourage the developer not to hold locks and other expensive objects on the caller thread, but the host can't do anything about it.

Of course, a plugin can spin off its own threads. While the API is not explicitly designed around multiprocessing, a plugin author is free to optimize for dual core within its contraints.

Yes, this is the way I now understand it as being. However, my more so layman's logic or common sense tells me that if the host's required process labor is evenly distributed across the width of two cores, that must (?) increase the efficiency with respect to the VSTs required process labor via the greater over all CPU load. Correct?

Let's say that the Ableton 5.2.2 (single core supported) CPU monitor reflects the current labor load of (25%) simultaneously recording 10 tracks, 5 Midi & 5 Audio. During this session I pull up the Stylus RMX plug in and the CPU load shoots up to 35-40%. Would not the same exact scenario with the 6.0 version (dual core supported) yield a 12.5% load and when the plug in was added a 22.5-27.5% total CPU usage? Thereby increasing the efficiency of over all process labor intensity with respect to the plug in's buffer and latency compensation resulting in better audio quality?

In this sense it's (the betterment) not specific to the VST software, but rather the duel core supported host as a result of it's intended duel core hardware adaptation.

In this sense, plain and simple, I would have to believe that duel core capability becomes a real advantage with respect to any task the appropriately supported host accommodates. (?)

Thanks4Consideration,
Jeff

[Richard Berg]

Would not the same exact scenario with the 6.0 version (dual core supported) yield a 12.5% load and when the plug in was added a 22.5-27.5% total CPU usage?

No, not really. All calls into a given VST plugin have to be on the same thread. Changing that would require revamping the API, otherwise legacy plugins that weren't threading-aware would blow up & die.

Things a multithreaded host can do:
* run tasks outside the main audio pipeline on different threads. in other words, spread their part of the load onto CPU 2 so that your audio plugins get CPU 1 all to themselves. in a sense all graphical hosts ever written do this; without threading, the UI would freeze every time you processed a chunk of samples. what "multicore-aware" programs do is start to optimize for higher CPU utilization overall, whereas traditionally you'd just focus on the routines that keep the UI snappy.
* run different tracks on different threads. so long as the mixing is done intelligently, this is a no-brainer
* call different plugins on different threads (personally I doubt they do this -- the synchronization would destroy performance in a significant # of cases)

The net result will be somewhere in between a dumb program hogging just 1 CPU and a perfectly balanced load. Where you land on that continuum is often as much about luck (your specific work habits) as skill.