aldous
Active Member
This isn't really a reply specifically to you Ben, more a "quick note" (ahem) to try to clear up a few things in the last few posts. The really quick version is that plugins aren't single-threaded, and can - and should! - correctly set-up scheduling policies for their threads, e.g. this, in the case of plugin threads in an AU.
The fuller explanation for anyone who's interested... in spoiler blocks to make it seem more interesting
Applications can tell the OS (MacOS, Windows, etc) how their processes/threads should be scheduled. This includes whether or not they need real-time processing. If an application doesn't do this, the OS may bump its thread from its CPU when a high-priority task arises, and your video/audio will stutter. This can happen even if the machine is largely idle: simply moving cores can be enough. If the OS does know about the real-time processing, it'll try to protect that thread's CPU time: the app may still stutter, but only under much heavier load.
In a "neat" world, a plugin would use the DAW like a mini operating system: it gets all its threads from the DAW, which gets then from the OS, sets them up properly, and passes them to the plugin. That would mean the DAW sets scheduling up consistently for everything, and it knows about all the plugins' threads. That's important because it means the DAW can intervene even when there are more real-time threads than there are CPU cores, preventing a free-for-all.
In the real world, plugins talk to the DAW about audio processing but are mostly free to talk to the OS about everything else, including the creation of threads. This means different plugins may behave differently because of how they set-up their threads, and that plugins can disrupt processing for an entire project by creating too many.[1]
[1] Things are a bit more organised on MacOS, as Audio Units are loaded in a sandbox where their activities are - at least theoretically - more controlled. This is why I thought Logic might be performing better in @Olympum 's original post.
In the real world, plugins talk to the DAW about audio processing but are mostly free to talk to the OS about everything else, including the creation of threads. This means different plugins may behave differently because of how they set-up their threads, and that plugins can disrupt processing for an entire project by creating too many.[1]
[1] Things are a bit more organised on MacOS, as Audio Units are loaded in a sandbox where their activities are - at least theoretically - more controlled. This is why I thought Logic might be performing better in @Olympum 's original post.
Firstly, a safety warning: please don't blindly enter commands from random guys on the internet unless you understand them or have checked the man pages, or some other reputable source. That goes double for anything involving
You can see how a plugin creates threads fairly easily, by typing
Finally, theoretically you can disable cores on MacOS using
sudo.You can see how a plugin creates threads fairly easily, by typing
ps M <pid> at a terminal (this is on MacOS), where <pid> is the Process ID (PID) of your DAW, or - for Logic - AUHostingService. (You can get the PID from Activity Monitor, or using ps x | grep AUHosting.) ps M will show the threads associated with the process you specify, along with their priorities. If you add another plugin and re-run the command, you'll see new threads have been created.sudo taskinfo --threads <pid> will give you even more information, but it'll only be comprehensible to someone who knows about the details of operating system scheduling and has read the (spotty) Apple documentation. But, if I were trying to find out how a plugin's handling its threads, that's where I'd probably start (if I didn't have the Xcode Instruments anyway.)Finally, theoretically you can disable cores on MacOS using
cpuctl, but I suspect this doesn't work on Apple silicon, or maybe it only works in Recovery/with SIP disabled. I'd definitely put this in the "don't do that" category.
