4 ms·
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 solu
by 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 agoha, yeah. No real time audio person trusts the OS scheduler anymore than is totally and unavoidably necessary.
- varispeed 6y agoBut how Ableton is doing it is worse than OS scheduler, that's the point.
- qppo 6y agoI 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 agoIt'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.
- qppo 6y agoIt shows how slow your CPU's single threaded performance is and the trade off between latency and throughout in modern computing more than anything. 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.
- varispeed 6y agoI am using i9 9900k @5GHz so I think it is quite fast. The plugins I use are CPU heavy and you can run limited number of them on a single core. I am not interested in low latency - I am running 1024 buffer, however I would like my projects to play smoothly even if there is latency. Ableton unfortunately does not work well with such use case as it won't parallelise where it could and sandboxing does just that and I can run more plugins, even if it seems less efficient.
- spacechild1 6y agoFor 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
- varispeed 6y agoI didn't observe that. I have experienced no difference apart from improved performance.