rgames1 wrote:ramses wrote:it would be around 12ms at 512 samples.
Yes, understood. That is consistent with what I measured and what shows up in Cubase.
To be clear, I cannot run that project at 512 samples on the BF. I can run at 512 samples on the Realtek but, as you pointed out, there are other buffers involved, so the real buffer size is unknown but certainly larger than 512. But it doesn't matter because the buffer size is not the metric I care about. That's why my original post mentions the latencies, not the buffer sizes.
Anyway, given that RME has a reputation for lower latency than onboard audio, if anyone has any ideas on why I can't get it then please let me know.
Thanks,
rgames
All channels of a recording interface, no matter whether in use or not, are instantly being transferred over FW/USB/PCIe.
The Realtek has fewer channels compared to the BFP.
It could be that the higher buffer size for the BFP is needed because your laptop cannot process audio data in time, if a smaller ASIO buffer size is being chosen.
Along with a smaller buffer size the CPU needs to react faster to I/O, this also means higher CPU load and a higher interrupt rate.
Some systems have higher internal processing latencies (DPC latencies) or energy saving cannot be turned off fully (laptops to prevent overheating). This can lead to a situation, that a few channels more can make a difference and that you need to select the next higher ASIO buffer size to prevent audio drops.
At least I can tell you that the BBF Pro has the same good performance – according to the selected ASIO buffer size 1024 – as all other RME devices would have. The BBF Pro has no worse driver / performance compared to flagship interfaces like UFX+ or a PCIe based RayDAT.
You could try to inspect and optimize your system further, some systems allow for a little better (lower) DPC latency, so that the CPU cores are not blocked for too long by badly written drivers. Drivers are coded according to programming conventions. The process scheduler is not allowed to interrupt executed drivers (low-level routines) otherwise you can't ensure data integrity. Drivers – once running on a CPU core – need to detach themselves from the CPU core after a while (programming conventions). There are certain drivers that over stress their time budget, maybe because the programmer didn't know better or perhaps to reach better performance values in benchmarks, who knows.
You can use the tool LatencyMon to look for drivers with too high DPC values. Try to disable not needed devices/drivers (Wireless, Bluetooth and alike). Or sometimes one driver version works better than another.
Many years ago I had issues with my Lenovo Laptop caused by the internal graphic chip in the CPU.
Luckily, I had a 3rd party nVidia chip built-in. Once I used the nVidia chip for Firefox, all audio drops during music playback were gone, even at the lowest ASIO buffer size of 48 (old UFX). Before, I had to compensate this issue with a buffer size of 256.
At the end of the day, you get the best performance
— using desktops, not laptops
— using selected components and drivers (check DPC performance with LatencyMon)
— getting rid of energy saving settings in BIOS, Windows and on your GPU (powermizer tool for nVidia)
— using the best suited Windows energy saving profile (Ultimate Performance)
— also prioritizing background services on Windows can still help.
— depending on the DAW, enabling MMCSS for ASIO in the RME driver can also make a difference
A collection of URLs with tuning tips you can find here, maybe you find something additional / interesting for you:
https://forum.rme-audio.de/viewtopic.ph … 04#p186404
With a nicely selected / tuned system you can reach an excellent performance, see my blog:
https://www.tonstudio-forum.de/blog/Ent … cks-de-en/
https://www.tonstudio-forum.de/blog/Ent … mponenten/
https://www.tonstudio-forum.de/blog/Ent … -X10SRi-F/
BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14