5 ms·

It seems like they say nothing whether they optimised their audio engine. There are a couple of low hanging fruits that they avoid to pick for some reason that

It seems like they say nothing whether they optimised their audio engine. There are a couple of low hanging fruits that they avoid to pick for some reason that would vastly improve the performance. For example they could enable wrapping the VST plugins in their own separate processes. That means the operating system scheduler would be able to distribute the load on available cores in a more efficient way than Ableton currently does. Another is that when you have two tracks using the same send, then all paths that lead to the send with the send included work on the same core that means you can easily run into issues if you use more demanding plugins. Here the solution would be processing the tracks in parallel up to the point where it goes to the send - this could actually be solved by running plugins in separate processes. One more feature related to performance improvements would be ability to freeze tracks just partially and freeze entire groups. I think other features added are great, but they are kind of useless if you can't play anything because the audio engine can't keep up.

mhh__ 6y ago
Bitwig already does that with VSTs IIRC
- varispeed 6y ago
  Yes and that works very well. You could also achieve this in Ableton by using jBridge (it was intended as a way to run 32bit plugins in 64bit DAW or other way around or to overcome the memory limits of a 32bit process) which runs plugins in separate processes and unintended consequence is vastly improved performance. I remember having projects that wouldn't play at all and played through jBridge without breaking a sweat.
  - spacechild1 6y ago
    For other readers: It is a misconception that sandboxing per-se enables parallelism. On the contrary, it only hurts performance. The speedup observed with jBridge might have other reasons. More here: https://news.ycombinator.com/item?id=25068976 https://news.ycombinator.com/item?id=25068976
PaulDavisThe1st 6y ago
> wrapping the VST plugins in their own separate processes. This isn't an optimization. https://ardour.org/plugins-in-process.html 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.
- varispeed 6y ago
  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.
qppo 6y ago
The problem is reducible to maximum directed cuts in arbitrary DAGs, which is hardly "low hanging fruit." The OS scheduler is a particularly poor choice of solution and introduces a ton of overhead while solving it suboptimally. 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.
- iainctduncan 6y ago
  ha, yeah. No real time audio person trusts the OS scheduler anymore than is totally and unavoidably necessary.
- varispeed 6y ago
  But how Ableton is doing it is worse than OS scheduler, that's the point.
  - qppo 6y ago
    I don't have access to Ableton's source code so I can't benchmark it to tell you if it's doing better or worse than the OS scheduler, but I would be shocked if it was worse. The penalty for even thread synchronization is quite high, let alone interprocess sync'ing. Particularly when it comes to latency. 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.
    - varispeed 6y ago
      It's from my experience. Ableton is optimised to cram as many plugins onto a single thread as possible, which means you are quickly going to run out of processing power when using more CPU demanding plugins, because as soon as you exhaust one cpu core, the project will no longer play in real time. When plugins run from their own process, the OS take care of distributing the load across multiple cores and that lets you run more plugins before it will overload. So I agree that sandboxing is not done to gain perfomance, but better perfomance is an unintended side effect. That shows how bad Ableton scheduling is.
spacechild1 6y ago
> this could actually be solved by running plugins in separate processes. 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.

mhh__ 6y ago

Bitwig already does that with VSTs IIRC

varispeed 6y ago
Yes and that works very well. You could also achieve this in Ableton by using jBridge (it was intended as a way to run 32bit plugins in 64bit DAW or other way around or to overcome the memory limits of a 32bit process) which runs plugins in separate processes and unintended consequence is vastly improved performance. I remember having projects that wouldn't play at all and played through jBridge without breaking a sweat.
- spacechild1 6y ago
  For other readers: It is a misconception that sandboxing per-se enables parallelism. On the contrary, it only hurts performance. The speedup observed with jBridge might have other reasons. More here: https://news.ycombinator.com/item?id=25068976 https://news.ycombinator.com/item?id=25068976

PaulDavisThe1st 6y ago

> wrapping the VST plugins in their own separate processes. This isn't an optimization. https://ardour.org/plugins-in-process.html 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.

varispeed 6y ago
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.

qppo 6y ago

The problem is reducible to maximum directed cuts in arbitrary DAGs, which is hardly "low hanging fruit." The OS scheduler is a particularly poor choice of solution and introduces a ton of overhead while solving it suboptimally. 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.

iainctduncan 6y ago
ha, yeah. No real time audio person trusts the OS scheduler anymore than is totally and unavoidably necessary.
varispeed 6y ago
But how Ableton is doing it is worse than OS scheduler, that's the point.
- qppo 6y ago
  I don't have access to Ableton's source code so I can't benchmark it to tell you if it's doing better or worse than the OS scheduler, but I would be shocked if it was worse. The penalty for even thread synchronization is quite high, let alone interprocess sync'ing. Particularly when it comes to latency. 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.
  - varispeed 6y ago
    It's from my experience. Ableton is optimised to cram as many plugins onto a single thread as possible, which means you are quickly going to run out of processing power when using more CPU demanding plugins, because as soon as you exhaust one cpu core, the project will no longer play in real time. When plugins run from their own process, the OS take care of distributing the load across multiple cores and that lets you run more plugins before it will overload. So I agree that sandboxing is not done to gain perfomance, but better perfomance is an unintended side effect. That shows how bad Ableton scheduling is.

spacechild1 6y ago

> this could actually be solved by running plugins in separate processes. 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.