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

Options
J.T.
J.T. Member Posts: 14 Member
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)
Tagged:
«13

Comments

  • Milos
    Milos Member Posts: 1,971 Guru
    Options

    Hmm...well...for more complex libraries that I tested (Session Guitarist), it does take at least nearly 20 seconds to load inside my laptop, but it is not really that much of a problem.

    But as for loading any instrument from Factory Library, it takes 2 seconds only.

    But again, not really the end of the world.

  • stephen24
    stephen24 Member Posts: 296 Pro
    Options

    The ASIO buffer is related to the audio output during playing and it's hard to see how it could possibly have the slightest effect on loading times.

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

    My thoughts exactly, which is why I'm so surprised by the results of my multiple tests (even on different PCs). Maybe it's some Kontakt related bug? Would be nice if some more people manage to replicate this phenomenon.

  • reffahcs
    reffahcs Member Posts: 848 Guru
    Options

    How are you conducting the tests? Try doing them in reverse order and see if the results change. In other words if you test 2048 samples first then 256, try setting it to 256 first then switching to 2048.

    I don't have Electric Keys, so I can't test your use-case. Does the same issue affect the Stradivari Cello? That's a fairly heft library that always takes a while to load for me on my Mac.

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

    I made a video showing the difference, and I'm not 100% sure but I remember some of these libraries loading way faster in the past. As in, like a year or two ago, but I can't link it with a specific Kontakt version. (And who knows, maybe I just had a different buffer size set back then.)

    I can't embed or post the video link because my account is too new on here, but the YouTube url ends in /watch?v=vT0j869FgfI

    (Reminder: this also happens in the standalone version or in another DAW, with different ASIO drivers, and even on my other PC that has a fairly clean Win10 install.)

    As someone who's really tech savvy I'm kinda stumped.

  • reffahcs
    reffahcs Member Posts: 848 Guru
    Options

    That is very very odd to say the least. I see what you're saying. I'm afraid I don't have much experience with NI software on a PC so hopefully someone else will have some better insight. The only suggestion I would make is to try the WASAPI drivers and see if the same occurs. When you tried it on different computers, were you using the same Focusrite interface?

  • 6xes
    6xes Member Posts: 668 Pro
    Options

    the loading times would indeed increase if the load of the CPU is saturated!!

    the priority of the cpu to allocate resources to the buffer vs disk management resources is also weighed within the Kontakt plugin, and granted the buffer maintains its continous audio-output the CPU will inevitably re-allocate resources back to disk-management

    at least thats how i figure things in the background would operate!! (just guessing of course!! :D )

  • reffahcs
    reffahcs Member Posts: 848 Guru
    edited February 22
    Options

    That's kinda what I was thinking too, but a buffer of 2048 samples is not really that big at all. I mean CPU cycles-wise the difference is tiny.

    I tested this on my Mac Studio and there's no difference, at least that was noticeable. There's something else going on here. I'll have to give this a go on my PC this weekend.

  • 6xes
    6xes Member Posts: 668 Pro
    edited February 22
    Options

    afterall as interrupts take place between disk access and audio streaming it would all have to take place in a sequential order making sure the priority of buffering is paramount.... if the audio buffering is not high on the list of priority when loading takes place... then you will inevitably get drops of audio/crackles buffer underruns etc... which is why a single core performance is all important in the grand scheme of things!

    edit: couple this priority aspect with the cache.. and the cache being saturated.. some instructions that are queued will have to go the long route, physical memory vs cache memory or swap memory vs physical memory dependant on what elements of memory management is saturated (again just guessing LOL)

  • mykejb
    mykejb Moderator Posts: 1,279 mod
    Options

    Seems odd that the higher buffer size is slower, I'd have expected to be the other way around as the smaller the buffer the higher the CPU load. Having said that, it's unlikely you're playing at the same time you're loading the instrument, so again I'd not have expected it to make a difference. I'll do some tests later if I get chance.

  • Kubrak
    Kubrak Member Posts: 2,807 Expert
    Options

    I will do tests as well. It seems to me that since certain time loading time of libraries considerably rised up. And I have changed buffer size some time ago....

    It would be strange that it would matter, but maybe some heavy audio processing goes on on background while loading. Who knows....

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

    I was using the same focusrite interface and and was suspecting that it might be related to the issue, but I wiped any audio drivers of my 2nd PC, installed the latest ASIO4ALL and just used Kontakt Player Standalone with ASIO4ALL v2.

    I got the following test results (timed with my phone so not perfect):

    Buffer length / loadingtime in seconds
    2048 - 23
    1024 - 12.5
    512  -  7.2
    256  -  4.4 
    128  -  3
    64   -  2.2
    PC: win10 / intel 4790k / gforce gtx 960 / loading from ssd / ASIO4ALL v2.15 + Kontakt Standalone
    

    And these are from my main PC (once again timed with my phone's stopwatch)

    Buffer length / loadingtime in seconds
    2048 - 20.4
    1024 - 10.53
    512  -  5.7
    384  -  5.2
    256  -  5.1
    PC: win19 / Ryzen 9 5900X / AMD RX 6700 XT / loading from m.2 ssd / FL Studio ASIO + FL v21.2.3
    
  • stephen24
    stephen24 Member Posts: 296 Pro
    Options

    I have noticed that when closing then immediately reloading an instrument, loading time may be greatly reduced. I've always assumed because geographical allocation of files in memory - probably occupying a lot of the loading time - is not immediately lost on closing.

    Also, presumeably when loaded the Memory allocation in the instrument header is always the same. And you've tried doing it in the opposite order as reffahcs suggested.

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

    Yes I did, I posted a video above, but it's easy to miss because I can't embed videos or post links because my account is too new, but maybe this works: https://www.youtube.com/watch?v=vT0j869FgfI

  • Kubrak
    Kubrak Member Posts: 2,807 Expert
    Options

    The only correct way to test it is to restart computer between tests. And it would be much better to test it with native ASIO driver instead of ASIO4All.

    I will do the tests on my system. If I will encounter differences in loading time, I may try several different ASIO drivers of several audio interfaces I use....

Back To Top