Why do sample libraries need so much memory? And how do you know what sort of RAM to buy? Read on for everything you always wanted to know about RAM but were afraid to ask. . .
RAM is one of the biggest bottlenecks when it comes to smooth playback of digital audio, especially when large sample libraries are involved. We’ve all been there: splurging on some juicy Black Friday deal only to find that the monster 50 GB library we’ve just installed now causes our whole template to grind to a halt. At some point, an upgrade is inevitable.
So in this article I’m going to explain what RAM actually is, how it gets used by your DAW, why we music professionals often need so damned much of it, and what factors you should be looking out for when it eventually comes time to buy more of it.
Table of Contents
What is RAM?
The performance of a computer ultimately comes down to how fast your CPU (Central Processing Unit) can execute instructions. The CPU itself is the main factor in this, with the number of instructions it can execute per second being determined largely by clock speed — the number of execution cycles it goes through per second. A processor like the AMD Ryzen 5900X (as used in our CADENZA system) has a base clock speed of 3.7GHz — meaning it can execute instructions on each of its six cores 3.7 billion times a second — and it can boost as high as 4.8GHz. That’s a lot of instructions per second.
In order to process all those instructions efficiently, the CPU needs a ready stream of instructions to process. These are stored in pools of memory which are at various levels of physical proximity to the CPU. The closer to the CPU they are, the faster they are, but the less data they can hold. For instance, within the CPU there’s a tiny register file which contains the instructions for immediate processing. Right next door to it, on the same chip, are three levels of increasingly large cache (L1, L2 and L3). These are still relatively tiny, though: the Ryzen 5900X mentioned above has 768 KB of L1 cache, 6 MB of L2 and 64 MB of L3 cache.
Then there’s the Random Access Memory, or RAM. RAM is the main pool of instructions your CPU can access in a hurry. It doesn’t always need access to all these instructions, but if it wants to execute any set of instructions quickly, they’re going to need to be stored in RAM first. If an instruction isn’t already loaded into your RAM, it’s going to have to be fetched from one of your system’s storage disks — and even very fast disks like NVMe drives are no match for the speed of RAM. Not even close! So the more information you can store in RAM, the faster your computer can operate — and this is especially important when you’re dealing with real-time audio.
How does my DAW use RAM?
It’s not actually your DAW that eats up all your RAM — it’s the samplers your DAW hosts that tear through it.
Here’s why. Let’s say you have a full orchestral template in your DAW. Your expectation is that when you click on a track and hit a key on your MIDI keyboard, you hear the appropriate sound — a horn, cello, kalimba, djun or whatever — play back. What’s happening in the background is that your MIDI keyboard sends a signal to your sampler — again, let’s say Kontakt — to fetch a particular audio file corresponding with the sound you want. That audio file is then passed to your CPU, which needs to decompress it and send the audio data it contains to your audio interface for playback. And it needs to do all this in a handful of milliseconds if you want to feel like you are playing a virtual instrument in real-time.
So it makes sense that if the audio file corresponding to the sound you want to make is stored in RAM, your CPU is going to be able to get to work on it much — much faster than it could if it had to fetch it from disk first. But fitting every single sample from every one of your sample libraries into memory isn’t really practical, which is why a sampler like Kontakt uses what’s called a preload buffer. What this means is that when you first initialise a virtual instrument, only the first part of each sample is loaded into RAM. When you hit a key, the first part of the sample is instantly available to the CPU, giving your computer enough time to retrieve the rest of the sample from a storage disk before it’s needed. (Again, all of this takes place in a matter of milliseconds!)
Why do sample libraries need so much RAM?
It’s largely about those preload buffers. By default Kontakt preloads the first 60 KB of each sample into memory when you initialise an instrument. So if you want to have the entirety of, let’s say, Spitfire Symphonic Strings (with ~89,365 samples) loaded and ready for seamless real-time playback, you’re going to need over 5 GB of RAM set aside just for the first 60 KB of each sample. On top of this, Kontakt will also set aside a portion of your RAM to make sure there is enough room to stream the rest of each sample in as and when they’re required.
Multiple libraries soon add up, so the more breathing room you give yourself, the easier your life will be. When your RAM is fully allocated, your CPU needs to make more requests to your storage disks, which will slow down system operation and make your computer feel sluggish. Worse, it can result in audio data being processed too late to be sent to your audio interface in time, and this is what results in clicks, pops and stutters.
So how much RAM do I actually need?
If you use sample libraries extensively, the simple answer is: the more the merrier! The sheer size of modern sample libraries means we recommend 32 GB as the bare minimum for composers in 2022. However, if you’re someone who works primarily with synths and plugins, CPU speed is the more important factor to take into account. That’s because (with the exception of sample-based synths like Omnisphere) your CPU is actually generating the sounds rather than playing back pre-recorded samples.
As RAM modules perform best in multiples of two, a 32 GB system like our PRELUDE come with 2 x 16 GB modules, but it should be noted that many motherboards, including the B550 and X570 motherboards our systems use, support a maximum of four RAM modules of 32 GB each, i.e. 128 GB altogether. So if you decide to buy, say, 64 GB now but want to give yourself the option of adding another 64 GB down the line, you’d be best off buying 2 x 32 GB modules rather than the slightly cheaper option of 4 x 16 GB modules, to ensure you still have slots free for a later upgrade. (We give you the option to do either.)
What do "MHz" and "CL" mean when it comes to RAM?
Other than the sheer number of GBs of RAM you install, the other two variables to bear in mind when purchasing RAM are clock speed and CAS latency. These can make a big difference to your system’s overall performance. Clock speed (expressed in MHz) relates to how quickly your RAM can process data — much like a CPU, it’s the number of times the RAM cycles per second. The higher the number, the faster it can feed instructions to your CPU. To a large extent, this is a case of “the faster, the better”, but there are limitations to RAM speed depending on the density of the individual modules. You’ll find much faster 8 GB RAM modules for sale than you will 32 GB modules, for instance. (We generally use 3,200MHz kits for our machines.)
CAS latency (CL) is also important, as this indicates the number of RAM cycles it takes for your CPU to actually read data from your RAM. In this case, lower numbers are better. Taken together, clock speed and CAS latency will give you a “true latency” figure that represents just how fast your RAM really is. This is expressed in nanoseconds, which should give you an idea of just how quick this stuff is. The formula is (CAS latency/RAM clock speed) x 2000 = true latency. So sometimes we may swap out 3,200MHz / CL16 memory for 3,600MHz / CL18 memory, as they both have the same true latency of 10ns.
What's the deal with Apple's unified memory? Do I need less of it?
One of the things I hear frequently from people touting Apple’s M1-powered machines is that because these computers have “unified memory” they don’t need as much RAM as a “normal” computer. This isn’t true, and Apple has never actually made this claim as best I can tell. Unified memory is simply a pool of memory that is shared between two or more components. In the case of Apple’s M1 machines, which use a system-on-chip (or SoC) architecture, that means that the CPU, integrated GPU and a built-in “Neural Engine” can all share data that is stored in one place. This introduces certain efficiencies, especially for the integrated graphics, because there is no need for data to travel from the main system memory to a discrete pool of RAM dedicated to that particular component (e.g. VRAM). However, for audio purposes it actually means your GPU is consuming memory that might otherwise be used to store samples. For obvious reason, this isn’t a benefit.
Yes, Apple also solders its RAM onto the same package that houses the SoC and this also introduces some marginal efficiency gains by reducing the physical distance the data needs to travel between memory and processor. But the main reason Apple does this is to reduce energy consumption, something which is important for their mobile-led (and battery reliant) silicon strategy. (Apple’s M1 machines also have very wide memory bandwidths, a topic beyond the scope of this article, but as this mostly benefits the GPU it’s not of huge relevance to us anyway.)
In other words, if you are buying an Apple M1-powered machine, please do yourself a favour and ignore everyone telling you you don’t need as much RAM as a “traditional” computer. If you use a lot of sample libraries, you’ll want to get as much RAM as possible — especially given Apple’s soldered memory modules can’t ever be upgraded.