This isn't an optimization. https://ardour.org/plugins-in-process.html
And also, the kernel cannot schedule more efficiently than Ableton does, because it doesn't know the data dependencies between plugins.
> Live uses one thread to process a signal path. A signal path is a single chain of audio flow. In tracks where instrument or effect racks are used, with multiple chains in parallel, Live may use one thread per chain depending on how CPU-intensive each chain may be. If two tracks are "chained" by routings, for instance by a side-chain routing, a track being fed to a return track or any tracks being fed into each-other, they are considered dependent tracks and count as one signal path. Any dependant set of tracks will use one thread each.
https://help.ableton.com/hc/en-us/articles/209067649-Multi-c...
The way they allocate plugins to threads is very inefficient and wrapping each plugin in a separate process sidesteps it as the OS takes over the allocation to different cores.
Ableton's scheduling could be quibbled with, but it's better than the kernel can do.
Ps. I'm the original author of Ardour, a cross-platform DAW. We use a different model than Ableton for scheduling, but not that different. We run N threads (based on a user preference for how many cores to use) and they pull signal paths from a pool, process them, and go back for more. The result is "1 thread per signal path".
If you have plugins A, B and C spread across 3 signal paths, then you can certainly run them on different cores, which Ableton (and Ardour and almost any other DAW at this point) will do, by virtue on running each signal path in its own thread. The signal path/thread containing plugin A will execute on a thread/core, independently of the one containing B or the one containing C.
[ A, B, C ] --+
|
+--> [ G ]
|
[ D, E, F ] --+
However, sandboxing is absolutely not the simplest way to fix this. Ardour does not and will never sandbox plugins in processes. It just uses a topological sort and a dataflow algorithm to decide what can be run and when, and would execute [ A, B, C ] and [ D, E, F ] in parallel (or could, if on appropriate hardware), before finally running [ G ].
Moving plugins into a separate process has both overhead and complications, and is basically a crazy way to fix this issue, if indeed it is an issue as described.
Finally, please make sure you understand what Paul Davis has tried to explain you. He's a well-respected industry expert.
I think jBridge might actually collect the result of the subprocess in the next DSP tick. This means that the thread can go on to compute "C" because it can take the result of "B" from the previous DSP tick. Now you indeed have things run in parallel. However, this adds additional latency of 1 audio block. If you have several of such sandboxed plugins in a row, this can easily add up.
This is technique is sometimes called the "pipelining" (see "2.3" in https://www.complang.tuwien.ac.at/Diplomarbeiten/blechmann11...). Note that you don't need sandboxing for this. You can just as well dispatch items to a thread pool, so everything stays within the same process.
So I think the speed up you observe with jBridge has nothing to do with sandboxing per-se, but is just a side effect of its implementation. I can't prove this because I can't look at the source code, but for me this is the most likely explanation.
TBH, you don't seem to even try to understand our arguments. If a domain expert like Paul Davis tells you something, try to learn from him and not easily dismiss his arguments.
Even if that is the case, it doesn't change anything about the point I was trying to make... I acknowledge that jBridge gives you a performance boost, but you're wrongly attributing it to sandboxing. That's all I'm trying to say.
Supercollider (scsynth) and Pure Data - both I'm contributing to -, have single threaded DSP. Users told me that they can use many more VST plugins when they enable the pipelining option in my extension, which matches your experience.
Again, I can't look at the source code for jBridge. The only thing I know for sure is that sandboxing itself only causes performance loss.
To put it short: I think jBridge does “pipelining“ to avoid the context switch overhead. But pipelining can also be done without sandboxing, leading to even better performance. Without pipelining, sandboxing only gives you a performance loss. Sandboxing does not imply parallelism.
Are you sure? Because since your theory is based on grouping tracks, it is easy to test, by simply grouping all tracks in a Set with 20 or so tracks that use a decent chunk of CPU. Then all their CPU should shift from several cores into one single core/thread (according to your theory). Of course, being easy I already tested this with a Set that used Live's native devices (no CPU usage change), but I can't test with VSTs right now (none installed). Maybe VST hosting has that problem, but processing of audio summing, Live's own devices and M4L doesn't have any major problem with multi-core.
Sidechain is not mere grouping/routing like the chain PaulDavis described with ASCII art (different from Sends too), with sidechain the plugin needs the audio from the other track for actual DSP processing, that's why sidechained tracks become a single thread "dependant" signal flow.
That page also mentions Live can use one thread per Chain if needed (for non Live-users, Chains are internal routings inside one single track), so it clearly states Live can use more than one core for one single Track.
Also, plugins like u-HE's use multicore just fine for a single instance, if you disable their own multicore handling (which conflicts with Live's multicore handling).
For Live's own devices, I'm pretty sure multicore works just fine, just tested again with Groups and Sends.
Don't know what problem you have, but it is not simply Live's multicore handling, it is some specific scenario you hit upon.
Granted you can use a lot of heuristics to figure out simpler solutions since DAW graphs aren't arbitrary DAGs and you can get clever with how you allow them to be constructed, but it's non obvious. That's why parallel performance varies a lot between daw engines.
Sand boxing isn't done for performance reasons, and it's why you can disable it in bitwig. The sole purpose of sand boxing a plugin in its own process is because it is the only way to catch a segfault and prevent a shared library from crashing a host.
My experience from actually writing low latency schedulers in user space as well as the publicly available material - like in Ardour - suggests different conclusions from yours.
Keep in mind that a naive benchmark like "cpu usage" is entirely meaningless. What you look at is round trip latency required for a threshold of underruns/missed deadlines. Threading requires additional latency, and process synchronization even more. While I'm sure you report fewer underruns when splitting off into sandboxed plugins I'm suspicious if it's hitting the same performance as doubling or tripling the buffer size in terms of latency in the first place.
Speaking as an audio developer, you would certainly not run things in a seperate process to achieve parallelism. Instead you would use a thread pool.