5 ms·

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 y

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.
- varispeed 6y ago
  Yes this is what's happening in Ableton and by your description I'd love if Ableton did the same thing as Ardour. I understand sandbox is not the simplest, but it is exactly what jBridge does and it gives me better performance in Ableton, so by simplest I meant that Ableton wouldn't have to change how they do processing, as jBridge is just a wrapper - does not modify Ableton in any way.
  - spacechild1 6y ago
    Again, sandboxing is not done for performance reasons. On the contrary, it degrades performance because of the context switch and thread synchronization overhead. I am saying this as someone who has developed a VST plugin host with sandboxing options. Finally, please make sure you understand what Paul Davis has tried to explain you. He's a well-respected industry expert.
    - spacechild1 6y ago
      To elaborate why sandboxing itself can't help performance, let's assume you have an FX chain A -> B -> C and "B" is sandboxed. After you've computed "A", you take the output and pass it to "B". You then have to wait for "B" to finish before you can go on and compute "C". So while the subprocess for "B" might run in another thread, the main audio thread has to go to sleep. See how there's actually no parallelism at play? In fact, you lose performance because context switches and thread synchronization (especially wake up from sleep) takes time. 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.pdf 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.
      - varispeed 6y ago
        Your assumptions are wrong, because when you run jBridge A B and C are sandboxed. You are essentially running all plugins in its own processes. As I stated in other comments, the performance is improved even with the losses coming from context switching. The effect is I am able to run much more plugins than without jBridge without Ableton having a breakdown and task manager shows better core saturation. I also stated I don't care about latency - I run my projects at 1024 buffer plus plugins introduce their own delays, so sometimes it takes a couple of seconds to hear something after hitting play. That's fine as long as the playback is uninterrupted. I am running very CPU heavy plugins and that bring Ableton to its knees. Other DAWs handle it miles better - especially Reaper. Unfortunately I cannot get used to the workflow in other DAWs so I have to use workarounds. I am not sure why people keep defending this flawed architecture. It's what makes the Ableton community so toxic, but still better than Bitwigs though - if you dare to comment you dislike something about Bitwig you likely get crucified.

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.

varispeed 6y ago
Yes this is what's happening in Ableton and by your description I'd love if Ableton did the same thing as Ardour. I understand sandbox is not the simplest, but it is exactly what jBridge does and it gives me better performance in Ableton, so by simplest I meant that Ableton wouldn't have to change how they do processing, as jBridge is just a wrapper - does not modify Ableton in any way.
- spacechild1 6y ago
  Again, sandboxing is not done for performance reasons. On the contrary, it degrades performance because of the context switch and thread synchronization overhead. I am saying this as someone who has developed a VST plugin host with sandboxing options. Finally, please make sure you understand what Paul Davis has tried to explain you. He's a well-respected industry expert.
  - spacechild1 6y ago
    To elaborate why sandboxing itself can't help performance, let's assume you have an FX chain A -> B -> C and "B" is sandboxed. After you've computed "A", you take the output and pass it to "B". You then have to wait for "B" to finish before you can go on and compute "C". So while the subprocess for "B" might run in another thread, the main audio thread has to go to sleep. See how there's actually no parallelism at play? In fact, you lose performance because context switches and thread synchronization (especially wake up from sleep) takes time. 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.pdf 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.
    - varispeed 6y ago
      Your assumptions are wrong, because when you run jBridge A B and C are sandboxed. You are essentially running all plugins in its own processes. As I stated in other comments, the performance is improved even with the losses coming from context switching. The effect is I am able to run much more plugins than without jBridge without Ableton having a breakdown and task manager shows better core saturation. I also stated I don't care about latency - I run my projects at 1024 buffer plus plugins introduce their own delays, so sometimes it takes a couple of seconds to hear something after hitting play. That's fine as long as the playback is uninterrupted. I am running very CPU heavy plugins and that bring Ableton to its knees. Other DAWs handle it miles better - especially Reaper. Unfortunately I cannot get used to the workflow in other DAWs so I have to use workarounds. I am not sure why people keep defending this flawed architecture. It's what makes the Ableton community so toxic, but still better than Bitwigs though - if you dare to comment you dislike something about Bitwig you likely get crucified.