Audio latency is one of those little problems that may seem insignificant… until you try to record a vocal, play guitar, or use a virtual instrument and suddenly hear a delay in your headphones.
You sing, play a note, hit a MIDI key… and the sound arrives slightly later.
Only a few milliseconds.
Yet that tiny difference can completely change the way an instrument or recording feels.
We often hear a very simple explanation:
“Lower the buffer size to get lower latency.”
That is true, but it is only part of the story.
The more interesting question is:
Why can one computer run at a 64-sample buffer without any problems, while another computer starts producing clicks and dropouts?
To understand that, we need to look inside the computer and at the entire audio system: the CPU, memory, DAW, plugins, drivers, and audio interface.
What Is Audio Latency?
Audio latency is the amount of time between when a signal enters a system and when we hear the resulting sound.
Let’s take a simple example.
You speak into a microphone.
Your voice follows roughly this path:
Every stage can contribute to the total latency.
But one of the most important elements in computer-based audio is the buffer.
The Buffer: Why Doesn’t the Computer Process Audio One Sample at a Time?
At 48 kHz, each audio channel contains:
48,000 samples per second.
Instead of treating every sample as a completely separate processing event, the audio system groups samples together into blocks.
These blocks are called audio buffers.
Typical buffer sizes include:
32, 64, 128, 256, 512, and 1024 samples.
The buffer therefore determines how many samples are grouped together for processing.
And this is where the fundamental compromise begins.
Small Buffer = Lower Potential Latency
Let’s take:
48 kHz / 64 samples
The duration represented by one buffer is:
64 ÷ 48,000 × 1000 ≈ 1.33 ms
This does not mean that the CPU is guaranteed exactly 1.33 ms of processing time.
It means that 64 samples represent approximately 1.33 ms of audio at 48 kHz.
The real-time audio system must continuously process incoming blocks while also dealing with the DAW, plugins, drivers, interface buffers, operating-system scheduling, and other parts of the signal path.
With a 128-sample buffer:
128 ÷ 48,000 × 1000 ≈ 2.67 ms
With a 512-sample buffer:
512 ÷ 48,000 × 1000 ≈ 10.67 ms
So the basic relationship is:
Smaller buffer → shorter audio blocks → lower potential latency
Larger buffer → longer audio blocks → higher potential latency
However, a smaller buffer does not mean less total audio work.
The same audio stream still contains the same number of samples per second. The difference is that the system must handle smaller blocks more frequently.
How Many Audio Blocks Does the Computer Process?
At 48 kHz, the system receives:
48,000 samples per second.
With a 64-sample buffer:
48,000 ÷ 64 = 750 blocks per second
With 128 samples:
48,000 ÷ 128 = 375 blocks per second
With 256 samples:
48,000 ÷ 256 = 187.5 blocks per second
With 512 samples:
48,000 ÷ 512 = 93.75 blocks per second
With 1024 samples:
48,000 ÷ 1024 = 46.875 blocks per second
| Buffer | Blocks per second | Audio represented by each block |
|---|---|---|
| 32 samples | 1,500 | 0.67 ms |
| 64 samples | 750 | 1.33 ms |
| 128 samples | 375 | 2.67 ms |
| 256 samples | 187.5 | 5.33 ms |
| 512 samples | 93.75 | 10.67 ms |
| 1024 samples | 46.875 | 21.33 ms |
This is why low-buffer operation is demanding: the computer has to deal with many more processing events per second.
The CPU: The Worker Who Has to Finish on Time
Imagine a factory.
There is a worker whose job is to process incoming goods.
That worker represents the CPU.
The goods represent the audio data.
The truck delivering them represents the audio interface.
And each box represents an audio buffer.
With a 64-sample buffer, the truck delivers a small box, but the trucks arrive very frequently.
With a 1024-sample buffer, the boxes are much larger, but the trucks arrive less frequently.
The critical point is this:
The worker must finish processing one box before the next one arrives.
If he finishes early, there is spare capacity.
If he finishes just in time, the system works but has very little headroom.
If he is still working when the next box needs to be processed, the system misses its real-time deadline.
In audio, that can produce:
- clicks;
- pops;
- crackles;
- glitches;
- dropouts;
- audio interruptions.
This is the key to understanding low-latency performance:
The CPU doesn’t just have to work. It has to finish the required processing on time.
My Own Experience: Why Changing the Computer Made a Difference
This is something I personally experienced over the years.
I bought my PreSonus audio interface in 2017.
Since then, I have changed computers several times while keeping the same interface.
I went through configurations such as:
i7 ~2.8 GHz / 6 cores
then
i7 ~3 GHz / 8 cores
then
i9 ~2.9 GHz / 12 cores
and finally
AMD ~3.4 GHz / 16 cores.
With every computer upgrade, I noticed better stability when working with low buffer sizes and heavier projects.
If I represent that progression simply as a personal impression — not as a scientific measurement of latency — it could roughly be represented as:
50% → 60% → 75% → 90%
These numbers do not represent actual latency measurements. They represent my personal perception of the increase in performance headroom and stability between the different systems.
And the important point is that I did not change only the processor.
The RAM, motherboard, chipset, CPU architecture, memory subsystem, and overall platform also changed.
So it would be incorrect to attribute the entire improvement simply to CPU frequency or core count.
What I observed was that each more capable platform made it easier to maintain low buffer sizes and stable real-time processing, even as projects became heavier.
The computer was not removing milliseconds from the buffer.
It was giving the audio system more room to complete its work reliably.
CPU, Cache and RAM: How the Computer Handles the Data
The CPU is the main engine performing the calculations, but it needs fast access to the instructions and data required for those calculations.
A simplified view of the memory hierarchy is:
This is a simplified representation, but it illustrates an important principle:
The closer memory is to the CPU, the faster it generally is, while its capacity is smaller.
The CPU does not perform every calculation directly inside RAM.
It uses its registers and multiple levels of cache to keep frequently needed data close to the processing cores, while RAM provides a much larger working memory.
RAM: The CPU’s VIP Workshop
Think of RAM as a VIP workshop next to the worker.
The CPU does not want to constantly walk to a distant warehouse to retrieve everything it needs.
Frequently used data can remain close to the processor in its caches, while RAM provides a much larger workspace for the operating system, DAW, plugins, audio data, and other applications.
Our analogy becomes:
CPU = the worker
L1/L2/L3 cache = the tools and materials on the worker’s bench
RAM = the workshop
SSD/HDD = the warehouse
Audio buffer = the box being processed
Audio interface = the truck
DAW + plugins = the processing machines
It is only an analogy, but it gives a useful picture of how the different parts of the system interact.
Why Doesn’t the CPU Simply Work Directly From the SSD?
A modern SSD is extremely fast compared with a traditional hard drive, but it is still much slower than the memory used for active CPU processing.
Storage is primarily used to keep files and applications.
RAM is the system’s working memory.
When you open your DAW, the operating system loads the required programs and data into memory so they can be accessed efficiently.
If the system does not have enough RAM, it may rely more heavily on storage as virtual memory, which can introduce significant performance penalties.
For real-time audio, where processing must continuously keep up with the incoming stream, this is undesirable.
The SSD is therefore more like the warehouse, while RAM is part of the active workspace.
Does Faster RAM Directly Reduce Audio Latency?
Not necessarily.
Faster RAM can improve certain aspects of overall system performance, but it does not automatically mean lower audio latency.
Several factors matter:
- RAM frequency;
- memory latency;
- memory bandwidth;
- CPU architecture;
- memory controller;
- CPU cache;
- memory channels;
- project workload.
A modern DDR5 platform can provide significantly more memory bandwidth than many older DDR3 platforms.
However:
DDR3 ≠ automatically high latency
DDR5 ≠ automatically low latency
The entire platform matters.
RAM is therefore one component of overall system performance, not a direct replacement for CPU processing power.
CPU Frequency Is Not Everything
It is tempting to think:
“The higher the CPU frequency, the faster the CPU.”
A higher clock speed can certainly be beneficial, but it is not enough to compare two processors.
Performance also depends on:
- architecture;
- IPC (Instructions Per Cycle);
- clock speed;
- CPU cache;
- number of cores;
- number of threads;
- memory subsystem;
- thermal behavior;
- power management.
A modern processor running at 3.4 GHz can therefore be significantly faster than an older processor running at a similar frequency.
This is why comparing CPUs using GHz alone can be misleading.
Multiple Cores: Multiple Workers
Let’s return to our factory.
With one worker, everything depends on him.
With a multi-core processor, different tasks can sometimes be processed in parallel.
A modern DAW can distribute parts of its workload across multiple CPU cores, which becomes particularly useful when a project contains many tracks and processing tasks.
But not every process can run independently.
Imagine:
Plugin A → Plugin B → Plugin C
If Plugin B depends on the result produced by Plugin A, it has to wait for A to finish.
At the same time, independent tracks or processing tasks may be handled by other cores.
This is why both single-core performance and multi-core performance matter in real-time audio.
More cores do not automatically mean lower latency.
When the CPU Can’t Keep Up
Now imagine a heavy project containing:
- several virtual instruments;
- multiple reverbs;
- delays;
- EQs;
- compressors;
- limiters;
- oversampling;
- automation.
You choose:
48 kHz / 64 samples
The buffer represents approximately:
1.33 ms of audio.
The system must keep processing those blocks fast enough to maintain the continuous audio stream.
If it finishes comfortably early:
→ plenty of headroom
If it finishes just before the next processing deadline:
→ very little headroom
If it cannot finish in time:
→ clicks, crackles, glitches or dropouts
This is where computer performance becomes critical.
The CPU Can Be at 50% and Still Cause Dropouts
You can sometimes look at the operating system’s Task Manager and see:
CPU: 50%
while still experiencing audio problems.
Why?
Because overall CPU usage does not tell you how much work is being placed on every individual core or critical processing thread.
You could have:
Overall CPU usage: 50%
while one important audio-processing thread is close to its limit.
The result can still be a missed real-time deadline.
This is why overall CPU percentage alone is not always a reliable indicator when troubleshooting real-time audio.
What About Plugins?
Plugins can add significant processing requirements.
A simple EQ may require relatively little processing power.
Other processes can be much more demanding:
- complex virtual instruments;
- convolution;
- advanced reverbs;
- look-ahead limiters;
- oversampling;
- mastering processors;
- complex algorithmic processing.
Some plugins can also introduce their own processing latency.
A look-ahead limiter, for example, needs to analyze incoming audio ahead of the point where the processing will be applied.
To achieve this, it can intentionally delay the signal.
This creates additional latency.
That is why a processor that is excellent for mastering may not be ideal when recording through the DAW.
Buffer Latency vs Round-Trip Latency
This distinction is essential.
If you use:
48 kHz / 64 samples
one buffer represents approximately:
1.33 ms of audio.
But your complete recording latency is not necessarily 1.33 ms.
For a monitored input signal, the audio may travel through:
Microphone
→ A/D conversion
→ input buffering
→ DAW processing
→ plugin processing
→ output buffering
→ D/A conversion
→ headphones
The total delay can therefore be significantly higher than the duration of a single buffer.
This is why Round-Trip Latency (RTL) is an important measurement.
RTL describes the delay associated with the complete input-to-output path rather than simply the duration of one configured buffer.
The Role of the Audio Interface
The computer is only one part of the system.
The audio interface also contains several components and systems that can influence real-world performance:
- microphone preamps;
- A/D converters;
- D/A converters;
- clocking circuitry;
- internal buffers;
- monitoring circuits;
- DSP, when available;
- USB, Thunderbolt, or other communication hardware;
- the device driver.
Two different interfaces can therefore produce different real-world latency even when using the same:
PC + DAW + sample rate + buffer size.
The Driver: The Link Between the Interface and the Computer
The driver allows the operating system and audio software to communicate with the interface.
A poorly optimized driver can reduce real-time performance even on a powerful computer.
Conversely, a well-designed interface with efficient drivers can provide excellent performance on a properly configured system.
This is why an audio interface should not be judged only by its hardware specifications.
The interface, driver, and computer have to work well together.
Direct Monitoring: A Shorter Monitoring Path
Some audio interfaces provide Direct Monitoring.
In this configuration, the incoming signal can be routed directly to the headphones or outputs instead of passing through the complete DAW monitoring path.
Instead of:
Interface → Computer → DAW → Plugins → Computer → Interface
the monitoring path can be much shorter.
This can be particularly useful when recording vocals or instruments and an immediate response is important.
Choosing the Right Buffer
There is no need to use the same buffer size throughout an entire production.
Recording
Low latency is usually the priority.
Typical settings might be:
32 / 64 / 128 samples
depending on the performance and stability of the system.
Mixing
Latency becomes less critical, so you can often increase the buffer:
128 / 256 / 512 samples
or higher on demanding projects.
Mastering
Processing capacity and stability are usually more important than extremely low monitoring latency.
A higher buffer can therefore be perfectly acceptable.
The Smallest Buffer Isn’t Always the Best Buffer
It is tempting to think:
“32 samples is better than 128 samples.”
Not necessarily.
If your computer runs perfectly at 128 samples but starts producing crackles at 64, then:
128 samples is the better setting for your system.
The goal is to find the best balance between:
low enough latency + reliable processing
A slightly higher latency with a completely stable system is far better than extremely low latency accompanied by clicks and dropouts.
The Main Factors to Remember
Computer-based audio latency is the result of several elements working together:
CPU
The CPU performs the calculations required by the DAW and plugins.
Greater processing capability provides more headroom to complete those calculations reliably.
Cache and RAM
The CPU relies on its caches and RAM to access the data required during processing.
Memory performance contributes to the overall system, but RAM speed alone does not determine audio latency.
Buffer
The buffer groups samples into blocks.
A smaller buffer represents less audio per block and requires the system to handle those blocks more frequently.
DAW and Plugins
They determine how much processing the computer has to perform and whether additional plugin latency is introduced.
Interface and Driver
They handle communication, conversion, monitoring, and additional buffering.
The Real Meaning of Low-Latency Performance
The important question is not simply:
“Is my computer powerful?”
The better question is:
“Can my entire system complete the required processing quickly enough to keep up with the audio stream?”
That is the real challenge of low-latency audio.
A powerful computer does not magically remove the milliseconds represented by the buffer.
Its advantage is that it provides more processing headroom, allowing the system to complete complex audio processing reliably within the required timing constraints.
This is why upgrading from one computer platform to another can make such a noticeable difference in real-world audio work, even when the audio interface and nominal buffer setting remain the same.
Final Thoughts
Audio latency is not simply a matter of choosing a smaller buffer.
It is the result of an entire system working together:
Interface → Driver → Input Buffering → CPU / DAW → Plugins → Output Buffering → Interface → Conversion → Monitoring
The buffer creates a timing constraint.
The CPU performs the calculations.
The cache and RAM provide the data required by the processor.
The DAW and plugins determine the complexity of the workload.
The interface and driver handle communication, conversion, and additional buffering.
And the entire system has to keep up with the continuous flow of audio.
Ultimately, real-time audio processing is a race against the clock happening inside your computer.
Once you understand this, buffer settings become much easier to understand:
Small buffer = lower potential latency, but tighter real-time processing requirements.
Large buffer = higher potential latency, but more room for processing each block.
The goal is therefore not to choose the smallest buffer possible.
The goal is to find the smallest buffer your entire system can process reliably.