Audio Plugin CPU Usage Shootout
I have worked with digital audio production for over a decade and one of the things that has been a constant issue, in one form or another, is CPU utilization. I’ve mentioned in previous posts (“Don’t Fear the Reaper”) that the main driver to switch from ProTools to Reaper was that ProTools routinely choked out my CPU while Reaper handled that aspect much more efficiently.
Over the years, I’ve come to learn more sustainable — rather than simply immediate — methods to cut down on high CPU usage and the most effective one, of course, is reducing the number of plugins, be it per track or per mix. Either way, fewer plugins generally means less CPU usage. This isn’t always practical, but for the most part, it’s easier than switching DAWs mid-project.
An interesting situation has arisen, recently, that has forced my working from only on my beefy Windows-based system, Ryzengard — a Ryzen 7 5800x 4GHz system w/32GB RAM (mono-borking made it so I’m at half RAM capacity until I want to shuck out for 32GBx2 or, heck, 64GBx2) — that I would have to try really, really hard to induce audio stuttering in Reaper due to plugin CPU usage, to working on both the Windows system and my 2015 MacBook Pro. Now, the McBook is pretty well spec’d, as those things go, for 2015 — a quad-core 2.2GHz Intel i7 processor and 16GB RAM — but it still requires a gentle touch when using things that are from “the modern age” and require a bit more horsepower to work well.
Shared Custody
So, when it comes to working on my album tracks, they’re all stored on Ryzengard, the beefy system that handles this with ease. That means that when it comes to editing/recording/producing them on something other than Ryzengard, the choices are either to remote in via MS’s Remote Desktop application, or work on a local Reaper installation with projects that are stored on the network. Neither of these is really a good option.
Remoting in to a session on the Windows system introduces excessive audio lag which is more than a little irritating when trying to do things quickly and without substantial trial and error trying to figure out where within the lag the point in the audio is that you’re trying to work with. Working with projects created on the PC-side creates a problematic plugin dynamic whereby I just don’t have close to the plugins on the Mac as I do on the PC and while a chunk of it is that it’s price prohibitive to duplicate plugins — though getting better as more plugins now offer both Win and MacOS versions with the same purchase — there are still quite a few that are Windows only.
The point, here, is that the MacOS versions of plugins also present a challenge: a billion options. Well, that’s not true. There are only a couple, but the most significant is the AU or “Audio Units” which are Apple MacOS native, “deeply rooted in the MacOS framework,” and are supposed to offer greater efficiency than other plugin formats (AAX, VST, VST3) as a result. Here’s the thing… While this may be true in MacOS-native DAWs like GarageBand or LogicPro X, it seems to be quite the opposite in Reaper, at least for the plugins I’m using. N.B., I’m not using a Mx “silicon”-based McBook so this could skew the results inasmuch as my “being optimized for MacOS” might not be the current definition of “being optimized for MacOS.” As an aside, I put “silicon” in quotes because all integrated circuits — microchips, processors, coprocessors, RAM, etc. — are made of silicon. To differentiate and somehow infer that your chips are better because they use the capitalized version of the same substance as every other IC on the planet is both disingenuous and a false distinction. The M1 through M4 architecture, on the other hand, is where the difference and proper distinction lies. This may seem pedantic but the point remains, capitalizing “silicon” doesn’t make it any different than silicon used ubiquitously in every chip in every other electronics anything.
Plugs and Plugs and Plugs and Plugs
One of the staples of my production workflow is the FabFilter suite of plugins. I’ve been using them for years and you’d be hard pressed to find a better EQ (for my workflow…) than Pro-Q, or the accompanying Pro-C2 for compression. You probably have your own preferred EQ/comp combo platters, but this is what I’ve been using, so this is what I’m measuring, today. I figure these two are, at least for me, probably the ones that may have to be put on each track individually since different tonalities and dynamics will be required for each. In my case, today, I’m just looking at the drums since I’ve got tracks or kick, snare, each tom, hats & ride, splash & crash, a track each for overhead 1 & 2, and room 1 & 2.
Get Kon16ov’s stories in your inbox
Join Medium for free to get updates from this writer.
So, with each track needing an EQ/comp combo that’s slightly different than the other, that’s 11 instances of the Pro-Q4 and Pro-C2 plugins. It may not be optimal, but for our purposes it also allows individual track CPU utilization monitoring, which is the point.
I decided, since I was on McBook, to try the AU versions of each plugin. My assumption was that since it was “optimized for the MacOS” that it would be more CPU-friendly than the other formats. This, my friends, was not the case at all. I added the AU Pro-Q4 and Pro-C2 plugs to the first 4 tracks (kick, snare, floor tom 1, rack tom 1) and upon playback I noticed two things: 1) there was already CPU-based clipping/crisping/crackling of the audio, and B) the CPU utilization on the Performance Meter had each track’s FX CPU value between 1.8% and 2.5%. While this may not seem like much, cumulatively, just these 4 tracks total between 7.2% and 10% utilization. That’s on top of any other usage resulting from a virtual instrument or general DAW overhead.
So, the AU utilization was not great. How do they compare with the VSTx versions’ usages? After replacing the AU versions of Pro-Q4 and Pro-C2 with their VST3 versions, the utilization drop was immediate. For the kick and snare, the average in-use utilization hit 0.47% and 0.73%, respectively. Oddly, the floor and rack tom tracks remained at 1.3% and 1.2% respectively which was still an improvement, but not as much as the others, including the rack toms 2 and 3 that dropped to 0.46% and 0.47%, respectively. With the four tracks initially measured, it was a pretty consistent 3.7% usage. This is just under half the CPU usage of the AU plugins. With the other two tom tracks added in, it was still only 4.8% and thus ~2.4% lower than just the initial four tracks measured for the AU-based plugins. In fact, with all 11 tracks switched over to VST3, it peaked at just over 5.2% thus clocking in at right around 2.1% less usage than just the four AU-based tracks.
A new contender has, indeed, entered the game. The CLAP-based plugin versions were included in the MacOS installation package and are supposed to be much more optimized than either the AU or VSTx versions. What do they bring to the table?
In the case of the kick, the CLAP versions of Pro-Q4 and Pro-C2 clocked in at 0.48% while the snare measured 0.75%. The floor tom sat at 1.2% while rack tom averaged 1.3% — reversed from the VST3 measurements, but still almost identical. Rack tom 2 didn’t change much, either, measuring 0.49%, but tom 3 increased to 1.5%. So, with the exception of rack tom 3, the differences were negligible and still way below the AU measurements.
Lock, Stock, and CPU Usage
I also decided to throw caution to the wind and see what I would see using the Reaper stock plugins for EQ (ReaEQ) and compression (ReaXcomp). The settings were matched as close as I could get them, and produced pretty close to identical sonic results. The CPU utilization, however, was not close to identical.
Unsurprisingly, the lighter weight plugins — in VST format — used a boatload less CPU processing power, all measuring at an average of 0.35% utilization. The brought the total utilization for all 11 tracks, using the ReaEQ and ReaXcomp VST plugins to 2.17%. That’s a significant processing savings for almost identical results. Was more tweaking required to get the exact sound I had dialed in on the FabFilter plugs? Of course — but that’s because of the tweaking I had already done in the FabFilter plugins.
Conclusions
If you’re not using the stock plugins, as is your choice and comfort level — I tend to shy away from overly simplistic GUIs, apparently — on the MacOS, then the results speak for themselves. The AU-based plugins utilized almost twice as much CPU usage as their VSTx counterparts, consistently. I would need to measure them within LogicProX to see if the completely native ecosystem changed anything, usage-wise. That said, I don’t know my way around LogicProX to give it even remotely a fair shakedown, so I’m thinking that’s either better left for someone who knows what they’re doing in LPX or we just stick to the scope of what I was measuring. So, again, if you’re going to use third-party plugins on the Mac, it appears at least to me that the VSTx/CLAP versions of the plugins will be more CPU efficient than their AU counterparts. This may change and it may depend on the DAW, but when looking at two fairly lightweight plugins, the AU’s CPU usage was twice that of the others. What I may need to look into is how that translates across more CPU-intensive plugins to see if it averages out across the versions, but that’s something for another day.
