Illustration: Maria Chimishkyan
Xfer Records’ Serum is a powerful, versatile wavetable synthesizer VST that has received near-universal acclaim from reviewers and everyday users alike.
Since its Rent-to-Own launch, Serum also happens to be the top seller on Splice’s Plugins store. Producers love its powerful wavetable tools, myriad modulation options, and functionality-packed UI. Some critics, however, have opined that Serum uses a disproportionate amount of processing power.
First, the synth uses a LOT of processing power. I hit a note on a super saw and saw my i7 dual core processor spike at 20%-30%. That’s a lot of number crunching for one instrument! This can be mitigated somewhat by using effects to simulate “unison” voices and (MAYBE) using a lower draft quality global setting. It’s just a function of math, if you want rich, fat, CLEAN sound, it’s just something we have to live with. If your computer isn’t beefy, you may have to drop your MIDI tracks to audio so you don’t kill your CPU.
Serum needs to be immediately put at the very top of any synthesist’s shopping list. It’s insanely powerful and sounds phenomenal.
PROS: Morphing oscillators. Flexible unison modes/ Built-in wavetable editor. Magnificent sound. Outstanding effects. Incredible modulation options.
CONS: Can hit your CPU hard.
STRENGTHS: Powerful wavetable synthesis. Extensive modulation and tone-shaping features.
LIMITATIONS: Can be CPU-intensive. No standalone version.
Despite near-universal praise for Serum’s sound, many reviews mention CPU efficiency issues. In this post, I’ll examine Serum’s CPU usage to determine whether these are valid complaints. I’ll find out why CPU issues might occur, take recommendations from Xfer devs, and test out those recommendations in comparison to fellow wavetable workhorse Massive.
Why is this happening to me?
Steve Duda of Xfer Records remains active in many online Serum communities including the Serum subreddit (where he’s the sole moderator) and Xfer support forums, where he has repeatedly encountered users who ask how to reduce Serum’s share of CPU usage. According to Mr. Duda, efficiency issues are typically attributable (at least in part) to user error:
Most CPU complaints I have found first and foremost come from heavy voice count compounded by not watching poly limits sensibly (lower-right fraction in Serum). Some synths won’t let that number exceed 64, so it’s good to keep an eye on it yourself and be sensible with unison (16 can sound great, but isn’t always better sounding!)
Sam Leggett, former Xfer dev, and current Splice audio scientist concurred:
Anything that is going to automate each voice separately increases the problem space by the number of voices, and if you have a lot of notes playing, e.g. in a chord stack, that will multiply said problem space by that many notes.
In other words, users may complain about high CPU usage if they crank up the voice count. Any digital synth must perform a certain number of calculations per voice in order to output audio. By the same token, when users increase the voice count, they’re also increasing the amount of numbers that their synth has to crunch in order to produce the desired sound. Since these calculations are performed by the computer’s CPU, increasing the voice count will increase CPU usage no matter what digital synth you use.
This post from Duda throws a little bit of shade at NI’s Massive, which caps the voice count at 64 and automatically redistributes voices to allow polyphony once the limit is reached. This prevents Massive from spiking the user’s CPU, even if the user raises the voice count and unison setting to their maximums. While voice count is not a bottleneck in most musical contexts, there may be legitimate cases where this limit is restrictive.
Imagine you wanted to play a dominant 13th C chord (C13) using a Serum patch with 2 oscillators on Unison settings of 8 each. That’s 7 notes (C E G B♭D F A), times 2 oscillators, times 8 = 112 voices. In Massive, these settings would trigger the voice cap, altering the timbral characteristics of the final output. Serum, on the other hand, does not limit voice count, meaning our 112-voice chord would use more CPU – although not on a per-voice basis, and without limits as to the patch’s desired timbre.
Another common potential cause of CPU inefficiency that Duda identified is excessive oversampling:
2x is all that is needed for normal oscillators, you shouldn’t hear any audible difference running 4x so it is indeed overkill. The 4x (oversampling) will be most noticeable when using FM warp modes, as it runs the oscillators at a higher sample rate which reduces digital artifacts. It will make some difference when using other warp modes as well.
Oversampling sounds like a cool parameter that will increase sound quality if you crank it up, but as usual Duda is correct. According to the Nyquist-Shannon sampling theorem, it should be possible to perfectly replicate a signal if sampled at or above the Nyquist rate (twice the highest frequency component in the signal). Therefore, an oversampling rate of 2x should be more than adequate for accurate representation of most signals.
What can I do about it?
For starters, it’s worth making sure that your copy of Serum is updated to the latest version. Updates to the codebase over the years have improved CPU usage, which may actually explain some of the efficiency criticism in the reviews. It should go without saying that a cracked Serum will result in degraded performance since it’s likely to be outdated and no updates can be applied. If you’re looking to own a legitimate copy of Serum, you can Rent-to-Own Serum for an easy $9.99 a month.
But let’s assume you’re all up-to-date and put Sam and Steve to the test. Below, we’ll try out some of the parameters they identified as potential CPU bottlenecks, determine their actual CPU impact, and assess their effect on Serum’s final output.
Will it work?
To test this out, I’ll be using my rMBP and the Splice studio Mac Pro.
For this test, I’m going to be be using Ableton Live 9 because there’s no standalone version of Serum. To measure CPU, I’ll use Live’s built-in CPU usage monitor, which monitors the peak usage across one processor core output from Live. I know what you’re thinking: “But I have 18-core hyp3rthr3ading d00d??!!!1” As a matter of fact, Serum uses only two core threads. Let’s hear again from Duda:
There’s a DSP thread and a GUI thread. This is the most optimal way to be for a typical project use, as the DAW will delegate instances (tracks) across cores. Running multiple DSP threads comes at a price and only allows for more out of a single instance, which tends to not be needed once people learn to limit polyphony reasonably.
It’s possible to capture more in-depth data using techniques like CPU usage profiling in Xcode’s Instruments, but since there’s no standalone version of Serum, there’s not much of a point in profiling its CPU usage independent of a DAW anyway.
Based on the recommendations I gleaned from Steve’s forum posts and talking to Sam, I’m going to test the following parameters’ impact on CPU usage peak within Live:
Voice count
- 32 (Serum and Massive)
- 64 (Serum and Massive)
- 128 (Serum only)
Oversampling
- 1x (Serum 1x, Massive Eco)
- 2x (Serum 2x, Massive High)
- 4x (Serum 4x, Massive Ultra)
Env1 release time
- 200ms
- 1000ms
- 32000ms
Reverb
- All settings 100%
Besides the above parameters, I’ll use an init preset with two saw oscillators. Oversampling will be set at 2x, Serum’s default, unless otherwise noted. Release times for Massive are estimated. I’ll play the same chords on all tests except for the voice count test. Each parameter will be tested three times and the final result will be the average of each run.
What happened?
Tl;dr
As the data demonstrates, CPU usage is positively correlated with voice count and oversampling for both Massive and Serum. Reverb may have had a slight CPU impact, as well as long envelope release times, but these correlations are much less severe than voice count and oversampling.
It would appear that Serum’s CPU usage inefficiencies are largely overstated. Compared to Massive, a popular competing wavetable synth, Serum performed significantly better on both desktop and laptop.
That said, I was able to get the Ableton processor meter up to 20% on the Mac Pro simply by asking it to generate 128 voices. This is a significant task even with a relatively simple synth patch.
The lesson here is clear: don’t crank up the voice count or the oversampling unless you really need them. Even 32 voices for one instrument is a relatively high number in a normal musical context. According to Duda, “7” Unison is the sweet spot for stacks/chords.” Your mileage may vary, but keep in mind that if you’re rendering 512 voices in real-time, you’re probably going to max out your processor.
If you absolutely must use hundreds of voices on your crazy FM patch with 4x oversampling and all fx maxed out, Sam Leggett has some suggestions for you:
One potential workaround for users who need fat chord stacks with tons of voices might be for instance to write your chord patterns with a lower voice cap, then when you’re ready, bring it up to where you want it and freeze.
In the menu at the top, there are options to resample to Osc A or Osc B. These will take the current output of the sound and its tail and put that into OSC A/B as its own wavetable. So if you do, for instance, a 16 voice unison with a little detune at the beginning, you can hit resample to Osc A and it will bounce that wavetable into Osc A as a single voice. It will also calc fx and everything else, so I would suggest maybe doing it right as you init your patch so you can still mess around with it after
Does Serum still spike your CPU? Are you ripping through renders with your Ryzen rig? Do you have other suggestions for saving CPU power? Let me know at @rewakmusic, and check out our Skills lesson for more in-depth video content on Serum.
Explore industry-leading plugins, bundles, DAWs, and more:
January 12, 2018
