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

2

Comments

  • D-One
    D-One Moderator Posts: 3,514 mod
    edited February 23

    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:

    Screenshot 2024-02-23 at 15.54.15.png
    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.
    J.T. Member Posts: 14 Member

    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
    PoorFellow Moderator Posts: 4,549 mod
    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
    Kubrak Member Posts: 3,056 Expert
    edited February 23

    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
    D-One Moderator Posts: 3,514 mod
    edited February 23

    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:

    Screenshot 2024-02-23 at 15.54.15.png

    Reverse test after reboot:

    Screenshot 2024-02-23 at 16.42.34.png

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

  • J.T.
    J.T. Member Posts: 14 Member

    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
    reffahcs Member Posts: 848 Guru
    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
    PoorFellow Moderator Posts: 4,549 mod
    edited February 23
    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
    Sunborn NKS User Library Mod Posts: 2,912 mod

    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.
    J.T. Member Posts: 14 Member
    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
    Sunborn NKS User Library Mod Posts: 2,912 mod
    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.
    J.T. Member Posts: 14 Member

    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
    Kubrak Member Posts: 3,056 Expert

    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
    reffahcs Member Posts: 848 Guru
    edited February 23
    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
    Kubrak Member Posts: 3,056 Expert

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

    Which patch have you tested?

This discussion has been closed.
Back To Top

Categories