Understanding REAPER CPU Performance

Why Projects Glitch Even When CPU Isn’t Maxed Out

If you’ve ever looked at REAPER’s CPU meter, seen plenty of headroom, and still heard clicks, pops, or dropouts, you’re not alone.

This is one of the most common points of confusion in modern DAWs, especially for users who understand computers reasonably well. On the surface, it feels like something must be wrong: the CPU isn’t maxed out, RAM isn’t full, and yet the audio engine can’t keep up.

The reality is more subtle. REAPER is usually reporting correctly — it’s just measuring something different from what most people expect.

---

Why Average CPU Usage Can Be Misleading in Audio

Most operating systems report CPU usage as an average across all cores over time. That’s useful for general workloads, but real-time audio doesn’t fail on averages.

REAPER isn’t asking, “How busy is the CPU overall?”
It’s asking something far more specific:

Can this block of audio be processed before the next buffer deadline?

If the answer is “no” — even for a single buffer — you hear a glitch. This is why a system can appear lightly loaded and still fail. Audio performance is governed by worst-case timing, not average utilisation.

---

Real-Time Audio Runs on Deadlines

Audio in REAPER is processed in fixed chunks called buffers. The buffer size defines how much time the system has to complete its work before audio must be delivered to the interface.

At 48 kHz, that timing looks roughly like this:

• 64 samples ≈ 1.3 ms
• 128 samples ≈ 2.7 ms
• 256 samples ≈ 5.3 ms

Within each of those windows, REAPER must process plugins, resolve routing, calculate automation, and hand audio off to the driver.

If any part of that work misses the deadline, playback breaks — regardless of how much CPU appears to be free elsewhere. In practice, the effective deadline can be slightly tighter than the maths suggests due to driver and OS scheduling overhead. There is an article on this website that covers Buffer Size & Latency in REAPER and how that can have an impact on your recording and playback experience.

---

Why One Core Can Break the Entire Project

Many parts of a REAPER session still rely on serial processing paths — work that must be completed in sequence and therefore cannot be spread across multiple cores at that moment.

Common examples include:

• Live input monitoring
• Serial plugin chains
• Master bus processing
• Certain routing and folder structures

REAPER exposes this clearly via its RT CPU meter— a measure of how hard the real-time audio thread is working against the buffer deadline. RT CPU reflects how much time the real-time audio thread — the thread servicing the sound device — is consuming relative to the available buffer window. Because that thread effectively runs on a single core, one overloaded real-time path can cause glitches even while total CPU usage remains low. In other words: the system may have capacity, but the critical path has run out of time.

---

REAPER Runs a Hybrid Audio Engine

This is the missing piece that explains why REAPER often appears to have “headroom.” REAPER uses a hybrid engine. When possible, it moves work off the real-time thread and processes it in advance using anticipative (pre-rendered) processing. This keeps RT CPU low most of the time and allows the real-time thread to assemble audio quickly at playback.

However, not everything can be pre-processed. Tracks that are record-armed, input-monitored, or otherwise constrained to “live” operation force more work back into the real-time path. As soon as enough processing lands there, the deadline pressure returns — sometimes abruptly. This is why sessions often feel stable until a specific moment, then suddenly glitch.

---

What This Looks Like in Real Sessions

A few common scenarios illustrate how this plays out. These examples aren’t edge cases — they’re typical points where real-time pressure shows up in everyday sessions.

A live vocal chain that behaves… until it doesn’t

A record-armed vocal track with pitch correction, saturation, compression, de-essing, and limiting forms a single serial chain. That entire chain must complete inside the buffer window, every time.

The session may look light overall, but that one real-time path determines success or failure.

The master bus as a deadline bottleneck

Master processing sits late in the signal graph and close to the output deadline. Linear-phase EQs, lookahead limiters, or oversampling-heavy plugins can behave fine on average yet occasionally spike just enough to miss the buffer window.

Because the master bus is unavoidable, its timing matters disproportionately.

Big routing reduces parallelism

Large sessions with deep folder structures, complex routing, and multiple sidechains reduce how much work can be processed in parallel. As dependencies increase, more processing is forced closer to the real-time deadline, shrinking margin even when total CPU usage looks comfortable.

---

Why the Performance Meter Matters More Than the CPU Meter

REAPER’s Performance Meter is designed to show real-time pressure, not just resource consumption.

In particular:

• RT CPU shows how close the audio device thread is to missing deadlines
• Views like “Longest block is realtime” help reveal worst-case offenders
• Per-track FX CPU highlights concentrated cost centres rather than averages

A project can run smoothly for minutes and still fail during a dense passage. Audio only cares whether each buffer arrives on time.

---

This Is Normal Behaviour — Not a REAPER Bug

This isn’t unique to REAPER. It’s a real-time audio constraint shared by all major DAWs.

Other platforms use different names — ASIO-Guard, Process Buffer Range, playback engine settings — but they all exist to manage the same fundamental problem: separating what can be pre-processed from what must run in real time. REAPER simply exposes the mechanics more transparently than most.

---

What This Article Intentionally Does Not Cover

This article is about understanding, not optimisation.

It deliberately does not:

• Recommend buffer sizes
• Suggest system or OS tweaks
• Offer plugin optimisation strategies
• Diagnose specific project failures

Those are practical next steps, but without understanding deadlines, RT CPU, and hybrid processing, they tend to feel random and fragile. This article is about building that understanding first. While this article deals specifically with unexpected glitches, you may find some of my other articles helpful if you need to work out Buffer Size & Latency in REAPER, or what to do if REAPER Has Input But No Sound.

---

My Final Thoughts

When a REAPER project glitches at low CPU usage, the system isn’t lying. Average CPU really is fine — while real-time scheduling briefly isn’t.

Once you stop thinking in percentages and start thinking in deadlines, the behaviour makes sense. You gain a clearer mental model of what matters, what doesn’t, and why some sessions feel effortless while others fall apart unexpectedly.

That understanding is the foundation for every meaningful performance decision you’ll make in a DAW.

---

I’d Love to Hear Your Thoughts…

Have you ever had a session that looked light on CPU but still struggled in specific moments?

Was there a particular track or chain that eventually revealed what was really going on?

---