Is it normal that increasing the driver's buffer size/latency increases library loading times?

J.T.

I noticed that some Kontakt libraries lately, especially those with more complex interfaces/functions/effects started taking quite a while to load, but after a ton of troubleshooting I realized that changing the buffer size of my driver can alter the loading times of certain libraries significantly, sometimes by 15 seconds!?

This seems to be about the loading times of the library's interface, not the samples and not Kontakt itself. One extreme example is Electric Keys Diamond, which takes 5 seconds to load with a Buffer Length of 256 samples, but over 20 seconds to load with a Buffer Length of 2048 samples! (Yes, I know you should try to keep the latency low, but big sessions need big buffer sizes.)

Maybe some of you can test if they get similar results? Ideally with modern libraries that don't use too many samples, but where the interface always takes a couple seconds to load.

I already tested it with: Different PCs, different DAWs, different audio interfaces, different ASIO drivers, Kontakt Player, Kontakt standalone, different Kontakt 7 versions.

(Here are some PC specs: Win10, Ryzen 5900X, Libraries and Kontakt installed on m.2 SSDs, Focusrite interface)

Find more posts tagged with

Kontakt 7

Comments

D-One

Interesting... I tested this with a big lib (Session Strings Pro 2) and got opposite results:

32 buffer = 9/12 seconds
2048 buffer = 6/7 seconds

So, for me bigger buffer = almost 2x faster. I did the test in the above order, so there's a chance some things remain in memory and are reused. For a more accurate test I'd have to do many passes and reboot each time to make sure RAM is cleared. I'll try it later.

(MacOS Sonoma, Ableton, External NVME around 800MB/s of read/write)

I screen-recorded to get somewhat accurate load speed measurements:

https://community.native-instruments.com/discussion/comment/135208#Comment_135208

Why are you using ASIO4ALL? You have a Focusrite interface, so you have proper ASIO audio drivers from Focusrite... ASIO4ALL is for old computer motherboards/interfaces that didn't support ASIO.

J.T.

Why are you using ASIO4ALL? You have a Focusrite interface, you have native propper audio drivers.

I tested it with ASIO4ALL, FL's ASIO and Focusrite, but initially I used my focusrite interface for tests on my two separate PCs and someone suggested I try not using the focusrite interface in case it's something related to the focusrite driver. That's why I uninstalled any focusrite stuff from my second PC and tried it using ASIO4ALL, so I could rule out that it's a focusrite thing.

PoorFellow

https://community.native-instruments.com/discussion/comment/135341#Comment_135341

I am with Kubrak on this one. And add to that maybe check the setting in "Loading" section for "loading in back ground" I don't know if that has any influence ? And of course , as Kubrak in-directly suggests then different drivers could work differently with Windows ..

Kubrak

I may even test the same driver using different HW. Each "family" of RME interfaces does use the same driver... I have 3 different interfaces from such a RME family.

D-One

Oh, I missed that @Kubrak post about ram/reboot, makes sense.

I've tried rebooting and doing the test in reverse order and indeed it affects things. The first load on a fresh boot is always the longest (12-14sec) regardless of which buffer size, So I guess that's the number that matters. IDK if this is due to cache/ram or the fact that external SDD's go into idle/power-saving mode when there's no activity and it takes them (at least mine) around 2 secs to wake up to read/write.

If I only restart the DAW then it gets faster each pass.

My conclusion is buffer size might have an impact but is rather insignificant and/or within the margin of error, but of course, if this is on a slow HDD drive then it can be quite noticeable.

Previous test:

Reverse test after reboot:

I doubt different interfaces will give different results in the same system.

J.T.

Also just as a reminder, this is mostly noticeable for me on libraries that have a heavy backend, so a lot of effects/programming going on for the GUI/effects, like for example the new Electric Keys (diamond/phoenix), heaviocity ascend, piano colors, the newer session guitarists libraries to a small degree, etc..

It's not really an issue at all for libraries that rely on (a lot of) samples and have a simple interface, like symphony series string ensemble, blueprint electric keys, etc.

reffahcs

https://community.native-instruments.com/discussion/comment/135372#Comment_135372

Now this makes more sense because the first load time is long and nothing is in cache. Once you've loaded a program it should be faster after that because certain bits of it will stored be cached in memory.

PoorFellow

https://community.native-instruments.com/discussion/comment/135376#Comment_135376

These days there are so much 'pre-fetch' built in that it can be hard to understand sometimes. Even in a CPU there are a predicted pre-fetch. Don't know at which level of cache though. And some CPUs got a lot of cache. Could exist in drives also (?) What Windows have 'Cached' in memory I don't know , I never cared enough about Windows internals beyond what I absolutely have to learn !

Sunborn

I see this matter brings a bit of confusion, while in fact it is very simple.

I will explain:

Audio latency has no direct connection with loading times.
But, it has indirect.
Lower latency leads to increased CPU load.
Increased CPU load, leads to longer loading time!

So, what leads to longer loading times is in fact the increased CPU load. Which of course, in this case, is a byproduct of lower audio latency.

So, D-One is correct when he wrote: "bigger buffer = almost 2x faster" (though 2x is not a "standard" but it depends on many other factors, for example your amount of RAM and if you use an SSD drive or not, etc.)

However: In high-quality music production, the desired, the requested, is the lowest possible latency. If a project takes few seconds more to load, is usually irrelevant. Personally i never even considered to measure them. What is a 5-10 seconds difference? Literally, a blink of the eye... I can also assure you that, for a "fast as hell" latency, many producers would happily sacrifice 10 and 20 seconds of extra loading!

By the way: 2048 samples, is extremely high for modern standards. I used this setting back in 2005 with the onboard Windows drivers. Today, a value of 1024 it should considered the maximum for WASAPI, but for a decent ASIO driver it is still too much! Of course (since it was mentioned) ASIO4All is far from a decent driver (if you need a virtual one, i strongly suggest Voicemeeter)!

Yet, there is a time and place for everything and everyone:

If your main goal is to play music (and even more, if you play live music) then, the lowest possible latency is the only way to go, especially if you also use hardware modules (synths etc.)
If your main goal is audio production (heavy recordings, mastering etc.) or audio post production (film, video etc.) then, a high latency is a "necessary evil".
If you do both, or you are somewhere in between, then your goal is balance.

Still, i do both the above and my latency never exceeds a buffer size of 256 for mastering works or 128 for music creation (i don't do films and video so i don't know what's best for them). :-)

J.T.

https://community.native-instruments.com/discussion/comment/135398#Comment_135398

You wrote

Lower latency leads to increased CPU load.

Increased CPU load, leads to longer loading time!

Yet for me it's the exact opposite, which is why I'm so confused. Low latency with a buffer of 64smp and it loads in 5 seconds, but a buffer of 1024 takes 10 seconds to load and with 2048 it takes over 20 seconds to load. Also only on libraries with a lot of effects/functions/GUI elements and not related to the amount of samples.

I may only be a hobby programmer, but for me it looks like a bug in some function or programming method.

Sunborn

https://community.native-instruments.com/discussion/comment/135402#Comment_135402

Yes, it is unusual, to say the least. I can't explain it with the provided details (i also see your video).

However if this is happening to you only (and judging by the other comments, i think this is the case) then we can't talk about "a bug in some function or programming method", but rather about some misconfiguration in your own system.

J.T.

I'm one of the last people who would point fingers and be like "Your buggy code makes my PC lag!!!1", which is why I tested this phenomenon for multiple hours on multiple PCs (that even have different CPU and GPU manufacturers) before even posting here. My second PC even has a fairly fresh Win10 install with not really any programs on it, yet it shows the same loading issues.

This is why I'm asking if other people could also do quick tests, especially with:

Windows 10/11
kontakt libraries that have smaller audio-sample sizes (<10GB)
kontakt libraries that have more complex functions/interfaces
testing it using smaller (128) and really big (1024/2048) buffer sizes

Kubrak

I can make tests on Win10, but tell me what Libraries. I have K13U CE and K14U, so I may test only that is included. From what you have mentioned, I have Piano Colors.

reffahcs

https://community.native-instruments.com/discussion/comment/135419#Comment_135419

Let me know what libraries you end up testing. I can do the same on mine, Windows 10 AMD box.

Kubrak

I will try Piano Color first, if it does something unusual, if you suggest it as a good candidate.

Which patch have you tested?

Quick links

Unanswered questions