3 ms·

That's not what my experience tells me. If you read on Ableton website: > Live uses one thread to process a signal path. A signal path is a single chain of aud

That's not what my experience tells me. If you read on Ableton website: > 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-core-CPU-handling-FAQ 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.

PaulDavisThe1st 6y ago
You should read the link I posted (I wrote it). 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".
- varispeed 6y ago
  I read the link. I think your assumptions are wrong and definitely don't match my use case. I know there is a cost of context switching, but even with adding all that I was getting much better performance. I work with 1024 buffer and use CPU heavy plugins. Let's say that my CPU (i9 9900k @5GHz) can run 8 plugins maximum on one core. Now I have 4 tracks, and each track has 4 plugins. That sounds okay, but as soon as I use a send effect on three tracks, they are being processed in one thread and that expects one core to serve 12+1 plugins. Suddenly I get overload and I can't play anything. If I use jBridge, the plugins on each track will run in parallel utilising all cores and playback is smooth. The cpu usage per plugin is higher because of the overhead of the wrapper, but I am able to much more plugins without breaking up. I think Ableton model does not take into account that you are bound by how many plugins one core can service and if you try to cram as many plugins into one thread you'll have performance issue. The strategy should be the opposite - trying to spread the load onto as many cores as possible.
  - PaulDavisThe1st 6y ago
    If plugins A, B and C are present in a given signal path, and ordered [ A, B, C ], then you cannot parallelize their execution. A must run first, then its output is fed to B, which must run to completion, and its output is fed to C. Using a single thread for this is the only sane implementation. 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.
    - varispeed 6y ago
      Let me try to explain again. In Ableton one signal path executes in one thread. Any track that goes to send or to a group gets added to one thread, so that if you have [A, B, C] on track one and [D, E, F] on track two - they will run in parallel - that's fine. However, if you send track one and track two to a send track with [G], they both run on a single thread, so it becomes [A, B, C, D, E, F, G], if a single core can only process four plugins, Ableton will be stalling. If you run each plugin in a separate process, then [A, B, C] and [D, E, F] will run in parallel and the results will go to [G]. As long as either [A, B, C] or [D, E, F] will not exhaust the single core, the playback will be smooth. The same happens if you group tracks or use side chain. Plugins in the chain will all run on single thread, but they could run in parallel up until the point where they "meet". Simplest way to achieve that is to do that sandboxing or more efficient way would be to improve the thread allocation to be more granular.
      - PaulDavisThe1st 6y ago
        The specific example you cite seems to be: [ A, B, C ] --+ | +--> [ G ] | [ D, E, F ] --+ If Live really insists on running [ A, B, C, D, E, F, G ] all in a single thread, then I agree with you, Live is being sub-optimal at best, dumb at worst. Despite their description supporting this notion that their scheduling works this way, I'm skeptical, because they're just not that dumb (I hope! :) 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.
- joeevans1000 6y ago
  As a side note... thank you for Ardour!!

PaulDavisThe1st 6y ago

You should read the link I posted (I wrote it). 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".

varispeed 6y ago
I read the link. I think your assumptions are wrong and definitely don't match my use case. I know there is a cost of context switching, but even with adding all that I was getting much better performance. I work with 1024 buffer and use CPU heavy plugins. Let's say that my CPU (i9 9900k @5GHz) can run 8 plugins maximum on one core. Now I have 4 tracks, and each track has 4 plugins. That sounds okay, but as soon as I use a send effect on three tracks, they are being processed in one thread and that expects one core to serve 12+1 plugins. Suddenly I get overload and I can't play anything. If I use jBridge, the plugins on each track will run in parallel utilising all cores and playback is smooth. The cpu usage per plugin is higher because of the overhead of the wrapper, but I am able to much more plugins without breaking up. I think Ableton model does not take into account that you are bound by how many plugins one core can service and if you try to cram as many plugins into one thread you'll have performance issue. The strategy should be the opposite - trying to spread the load onto as many cores as possible.
- PaulDavisThe1st 6y ago
  If plugins A, B and C are present in a given signal path, and ordered [ A, B, C ], then you cannot parallelize their execution. A must run first, then its output is fed to B, which must run to completion, and its output is fed to C. Using a single thread for this is the only sane implementation. 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.
  - varispeed 6y ago
    Let me try to explain again. In Ableton one signal path executes in one thread. Any track that goes to send or to a group gets added to one thread, so that if you have [A, B, C] on track one and [D, E, F] on track two - they will run in parallel - that's fine. However, if you send track one and track two to a send track with [G], they both run on a single thread, so it becomes [A, B, C, D, E, F, G], if a single core can only process four plugins, Ableton will be stalling. If you run each plugin in a separate process, then [A, B, C] and [D, E, F] will run in parallel and the results will go to [G]. As long as either [A, B, C] or [D, E, F] will not exhaust the single core, the playback will be smooth. The same happens if you group tracks or use side chain. Plugins in the chain will all run on single thread, but they could run in parallel up until the point where they "meet". Simplest way to achieve that is to do that sandboxing or more efficient way would be to improve the thread allocation to be more granular.
    - PaulDavisThe1st 6y ago
      The specific example you cite seems to be: [ A, B, C ] --+ | +--> [ G ] | [ D, E, F ] --+ If Live really insists on running [ A, B, C, D, E, F, G ] all in a single thread, then I agree with you, Live is being sub-optimal at best, dumb at worst. Despite their description supporting this notion that their scheduling works this way, I'm skeptical, because they're just not that dumb (I hope! :) 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.
joeevans1000 6y ago
As a side note... thank you for Ardour!!