Plugin Sandboxing

I have spent the past few days doing a bunch of research into plugin sandboxing. This is where plugins are run in a separate process from the DAW. The main advantage of doing that is that is so that if a plugin crashes or otherwise misbehaves, it doesn't take the entire DAW down with it. Instead, the sandbox process crashes, then the DAW can detect the situation and let the user know what happened and allow them to restart the sandbox if they want.

In Blockhead's case there are a couple more advantages:

• Blockhead's UI is implemented using Godot and so it's using OpenGL. This is pretty rare for a DAW and so plugin developers might not be anticipating it. If they are not careful then they might end up doing OpenGL calls which interfere with Blockhead's rendering.

• The code for opening up the plugin editor windows currently has to be a bit hacky because I don't have direct control over the main message loop of the application (because that's deep in the guts of Godot and not straightforward to modify.) The Linux version of Blockhead is currently suffering greatly from this problem.

Plugin sandboxing is a really complicated problem and there isn't much specific information about it online so my research has been more generally on the problem of "how do you transfer data between two real-time threads that belong to two separate processes, in a way that works on Windows, macOS and Linux?" The answers I am going with at the moment are "shared memory using the Boost.Interprocess library" and "busy-waiting with a tuned back-off mechanism". I've yet to find out how well my idea works.

It bugs me a bit that this problem is essentially a solved one (many proprietary DAWs already implement plugin sandboxing) but I still have to re-solve it myself, and it also occurs to me that the problem can be solved in a generic enough way that it would work for whatever type of sandboxing a DAW wants to do. For example, many DAWs will create a sandbox process per plugin instance like in this simple example of a project with a single track containing two effect plugins:

Another DAW might instead prefer to create one giant sandbox containing every plugin. The connections between the plugins are managed inside the sandbox. If one plugin crashes then it takes down the entire sandbox (probably with no way of knowing for sure which plugin was the one that crashed.) Then the DAW can present the user with the choice to restart the entire sandbox, or restart individual plugins. In my opinion this isn't that bad because a lot of the time it will probably be obvious to the user which plugin it was that crashed (it's probably the one that they downloaded from the internet 20 minutes ago.)

Some added complexities here are that some plugins have multiple inputs and outputs, and the DAW may want a way to inject additional input/output signals at various points in the signal chain:

This makes the inter-process communication a lot more fiddly but it's doable I think.

In my opinion, if it works then this second design is the way to go because:

• It's much more efficient than creating one sandbox per plugin.

• Even if you want to create one sandbox per plugin (perhaps giving the user the option), this design can still be used for that anyway, by simply creating multiple sandboxes which each contain a single plugin.

• A DAW may want to do some other sandboxing scheme, for example, creating one sandbox per track, and this design is compatible with that too.

My plan at the moment is to create an open-source plugin sandboxing system so that no DAW developer has to figure this crap out ever again. I will probably try to get something working with Blockhead and CLAP first and then put it on GitHub. If I'm lucky then someone may even come along and implement VST support for me so there's my ulterior motive.

The project is going to consist of three main parts, the sandbox process, a client library for interacting with it, and a plugin scanning process. The plugin scanner already exists - the one I use at the moment for Blockhead is clap-info. This is the process which launches automatically when Blockhead starts up and scans the system for installed CLAP plugins. Plugins can even crash when they're being scanned so that's why that happens in another process.

All interaction with the sandboxing system will happen through the client library, which will encapsulate the hairy problem of communicating with the sandbox processes.

So hopefully this all works in practice. I've done IPC in the past but the really tricky part here is that the communication is happening between two real-time audio threads, so it's necessary to avoid syscalls and traditional locking mechanisms. That is actually quite a funny stipulation because in a way it narrows down the list of possible approaches to the problem so much that, as far as I know, you are left with two options for the shared memory synchronization strategy: futexes, or busy-waiting.

Futexes are really only available on Linux. On macOS they are sort-of supported, but not in any official way. On Windows, futexes exist, but they don't work across multiple processes. So that leaves me with busy waiting. And I can do my best to reduce the CPU load by implementing some kind of intelligent back-off strategy.

Additional reading:

https://ardour.org/plugins-in-process.html
Developer of Ardour on why Ardour doesn't implement sandboxing at all. I don't really agree with the arguments here but I will readily admit that I don't know what I'm talking about. Maybe once I have more experience in this area I will better recognize these stated problems. The article is quite interesting and useful regardless.

https://timur.audio/using-locks-in-real-time-audio-processing-safely
Timur Doumler's article on busy-waiting. The situation described here is a bit different from mine (his problem involves one audio thread and one UI thread synchronizing access to some shared resource, rather than two real-time audio threads hopping data back and forth between two processes in the middle of an audio callback.)

https://shift.click/blog/futex-like-apis/
Information about the availability of "Futexes" on various platforms.