I try to explain, sorry a little long, but well … to really understand it, you need to know a few things.
The ASIO driver has latency values compiled in so that the DAW can perform latency compensation. This applies only to the directly attached analog ports, as the converter latency is known only for these ports.
You often hear the term RTL (round trip latency). This refers to the time required for A/D conversion, transport over USB (to the PC and back), and D/A conversion. The typical use case for this latency is when recording from a microphone and monitoring in the DAW through speakers. There is also a term called direct monitoring, where the recorded signal is sent directly to the output on the recording interface without being processed by the DAW.
The higher the sample rate, the lower the converter latency. However, this latency decrease is minimal and not worth it unless you truly need it. The significant disadvantage of higher sample rates is that they increase the amount of audio data to be processed, thus increasing system load.
The more channels a recording interface has, the more data needs to be transported over USB. All channels are transferred over USB, regardless of whether you are using them (with a few exceptions to this rule).
The ASIO buffer size has the most significant impact on RTL. The smaller the ASIO buffer size, the smaller the RTL, but the greater the risk of processing audio too slowly, leading to audio loss.
The audible latency (e.g., RTL) during monitoring is constant and depends solely on the sample rate and ASIO buffer size. No matter how powerful your system is, you will always get the same RTL. If your system is not powerful enough, the RTL remains the same, but you may experience audio loss because the audio could not be processed in time.
You may now ask yourself what a powerful system for a DAW load is, allowing you to run low ASIO buffer sizes without experiencing audio drops.
The truth is, everything has its limits—there is no system that can do it all.
What’s essential for a DAW system is that the CPU cores can work at full power and that you have drivers that do not block CPU cores for too long. The critical point here is that low-level routines (drivers) run with the highest priority on your system, and they are not under the control of the operating system’s process scheduler.
The process scheduler assigns processes and threads to different CPU cores in the hope that the CPU will start processing them as soon as possible.
To ensure data integrity, low-level routines (drivers) need to be processed even sooner. Therefore, they have the highest priority over user and system processes. A very important detail is that these routines run as long as they need to until they detach themselves from a CPU core. The duration that a driver runs on the CPU core is hard-coded in the driver based on "programming conventions." Some drivers are poorly coded and stay on a CPU core for too long, blocking the CPU from starting work on other processes that were scheduled by the process scheduler.
This latency inside the computer is called DPC Latency. It is not an audible latency, but it determines whether a system can work efficiently on all processes and threads.
The better the drivers, the lower the DPC latency, and the more headroom you have to configure smaller ASIO buffer sizes.
Then the system is agile enough to process audio in time, no matter which core the audio-related processes are scheduled to run on.
A performant system is one with many cores, but also with powerful cores. Often, it is also beneficial if they have high single-thread performance. Single-thread performance is important because some DAW-related tasks are processed on only one CPU core and cannot be split across multiple cores. These tasks also need to be processed in time.
As you can see, it is a complex ecosystem that needs to be balanced. Even the fastest system can result in poor DAW performance if the drivers are bad and if you have high DPC latency. Such issues do not show up in benchmarks, as benchmarks typically use all CPU cores, and it doesn't matter when the results arrive.
The big difference with DAW/audio processing is that it has real-time processing requirements. It is crucial that all audio-related jobs are processed on time because "too late" is simply too late, leading to audio drops.
A good strategy is to set up the PC properly. Avoid unnecessary tools that can block CPUs for too long. I have had bad experiences with tools from the motherboard vendor for automatic tasks like fan control, BIOS, and driver updates. They are often so poorly coded that they can significantly impact performance.
When setting up a new computer, I perform frequent LatencyMon measurements to monitor DPC latency. Again, this is not audible latency and has nothing to do with audio itself. It is the processing latency when jobs are being executed.
My first measurement is on a freshly installed system. I then try to achieve the best/lowest DPC values by fine-tuning the BIOS. All you need to do in the BIOS is disable energy-saving features. This is easier on a desktop system than on a laptop. On a laptop, energy-saving features are typically necessary to prevent overheating, and if the CPU gets too hot, its clock speed may need to be throttled, reducing overall performance.
Once the BIOS settings are optimized, I start installing only the necessary drivers. After each driver installation, I perform LatencyMon measurements again to check for problematic drivers. Finally, I install the applications, continuing to monitor DPC latency throughout the process.
On Windows, you should also select an energy profile that disables energy-saving features as much as possible. On a desktop system, you can use the hidden "Ultimate Performance" power profile. On a laptop, your options may be more limited; some systems do not even allow you to choose "High Performance," leaving you with only the "Balanced" mode.
Another helpful approach is to optimize the Windows process scheduler for background tasks. According to my research, this means that each job runs similarly to how it does on Windows Server systems, with a fixed and slightly longer time quantum. This allows the CPU to work more efficiently on a single task for a longer period, reducing the number of context switches. See my blog article:
https://www.tonstudio-forum.de/blog/Ent … es-or-not/
This is the process of gaining experience with your system, learning how computers work, and understanding the importance of having an agile system with low DPC latencies.
If the setup is nicely optimized and your DPC latencies are "ok" but you still cannot set ASIO buffers as low as you need or like, then it can be the case, that your CPU is not fast enough. Or it has not enough cores or is missing single thread performance. It can also be that the DAW project is not set up well.
Too many inserts on a track need higher single thread performance because audio needs to be sent through all inserts / VSTs and all this needs to be computed in time.
The more control you have over these factors, the lower the typical ASIO buffer sizes you can use in your DAW projects.
On average, you can work with lower ASIO buffer sizes on an agile computer with low DPC latencies.
But again, we are only talking about processing audio in time and avoiding audio drops.
The RTL depends solely on the chosen ASIO buffer size. The key point is how low the ASIO buffer size can be, based on your system’s performance (CPU, etc.) and low DPC latencies.
BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14
