I have probably been experiencing time load issue for quite some time. If I let the system sit for a while while running it would be making “gurgling” audio when I came back. I discovered that I could solve it by turning Cantabile on and off in the upper right corner. At the time I was not aware of the monitor tab, time load statistics, etc.
After purchasing a resource hog (SWAM string ensembles), I went through Brad’s Glitch-free document with some improvement but not enough. I plan to go back through that again.
I was naturally paying a lot of attention to peak time loads with SWAM. I hadn’t been paying much attention to normal time loads. But now I am noticing that my time load is sitting at 50-60% when I am not doing anything at all. Is that normal? Why is there any substantial time load when nothing is going on? The CPU load is only a few percent. I have never seen it go above 6-7%.
FWIW, I am running a core i9 with 32GB RAM and 1TB SSD. There is a fairly substantial set list loaded using almost half the memory. 30 racks, but only a few racks running at any particular time.
It’s totally dependent on which plugins are turned on.
I have been working with a setup that uses asio4all and the internal sound card, because I want minimal boxes at an upcoming event. Buffer at 128. Definitely not as efficient as using hardware, but if it copes, that’s good enough.
Right now, a Rhodes + Grand combo with a couple of amps and enhancers, a Relab Lex 480 and Val Shimmer is idling at :
CPU load 6.0 to 18%
Cantabile load 0.0 - 0.4%
Time load 35-40%
Other, more demanding patches which include
active cherry synths, miniverse, 2600 and mercury 4 in addition to Halion with several active channels and a variety of enhancers
CPU load 9 to 26%
Cantabile load 1.5 - 6.8%
Time load 47-55%
In use, the Time Load doesn’t go above 73%. System load around 40%
This is an i5 with ASIO4All.
This illustrates that the ASIO driver is critical to performance - that’s where time load can fail - BUT … as long as you’re inside the max, you should be click free - and it’s typical to see time load be way higher than CPU load.
I’ve been using this a little while, but I keep learning stuff. Today I built a simple setlist with one song and one vst. Depending on the one vst, the time load at idle varies a lot more than I would have guessed, That SWAM string section that gives me time load fits when I actually use it consumes almost nothing when idle. B-3X all by itself hits 40-50% when doing nothing but doesn’t go up all that much when you use it. But it’s not about the organ, it’s the effects. I had one electric violin setup with lots of effects that was idling at 90%. Thanks for making me aware of this. It’s something I need to learn to keep an eye on. I’m glad I sprung for the i9.
Yep, it’s surprising!
I forgot to mention VB3 and Waterfall Leslie.
That Leslie definitely ups the time load.
And, of course, virtual audio always benefits from speed; fast processors, ram, SSDs, but it’s still critical that the ASIO driver is efficient. There’s no point having a Ferrari sitting in a traffic jam.
Low latency is almost exclusively down to the ASIO driver, not so much the CPU.
And we’ve certainly been made aware of the quirks in Windows that puts a system into critical overload, but which can be remarkably revived by power cycling Cantabile. One could be fooled into thinking a system was beyond its capabilities, only to find it is more than happy when that little green button in the top right is flipped on and off.
It’s almost like Windows misallocates its resources and that button has the OS tidy up the mess which accrues. So weird.
Not a cantabile issue. It’s all down to the OS.
I’ve seen in another thread where prople are adding a binding to restart the engine on all song loads or song loads that use certain plugins. I may look into that
I suppose it shouldn’t be surprising that effects use more time load at idle as they must be running all the time. They have no way to “rest” when no notes are being played.
I recently switched to a MOTU M4 interface. It has its own ASIO driver. When I’m messing around with my laptop on my actual lap I switch to ASIO4ALL amd internal speakers or headphones. So far I’m not seeing a big difference, but I will be looking closer with knowledge gained today.
Look at the actual reported latency. You may find it is higher even with the same buffer setting, compared to your MOTU.
Cubase provides more comprehensive info, it appears. At a buffer of 128 under ASIO4LL the round trip latency reports as around 32 Ms.
The focusrite saffire, at the same buffer setting, reports at 8 Ms. Not all 128 settings are the same! (Assuming the reporting is correct.)
Nonetheless, ASIO4ALL still does a great job.
The binding to power is well worth doing, in light of what we now know.
@raydyo I have i7 13600, 2 2T ssds, and 64G ram. If i load a song with 12-20 vsts the timeload at rest can be anywhere from 28-50%. MOTU 828 (new) Buffer 128. Generally speaking timeload wil rise to 80% or so with 4 to 7 instruments actually playing at one time; if i use lots of damper pedal playing loudly i can overwhelm the driver but that rarely happens. It all depends on the instrument mix. B3x is especially egregious with timeload.
I would say what you are seeing is not uncommon. Try disabling vsts not being
currently used; that will help. But it realy depends on driver efficiency i think.
Thanks for the binding tip to recycle Cantabile!
Thanks for the info. I was was beginning to think that i had something seriously wrong. But now I know that I was just seeing things that I hadn’t noticed before. And now I know to keep an eye on that pesky time load. It’s all a bit disappointing. I thought I had plenty of juice to run most anything. It was those SWAM string ensembles that really opened my eyes. Probably a bad investment.
Just to pick up on this, Melda have a made a point of displaying a ‘Sleep’ notification on their plugins when they are not processing any input. They activate as soon as signal is detected. -and the response time is so fast as to be inconsequential.
Many manufacturers only seem to consider their plugins being used in a DAW situation, where playback mitigates the demand that we, who use software which needs to provide rock solid low latency results on demand, can’t benefit from the kind of buffer manipulation that DAW playback typically provides, and which hugely improves potential. We, on Cantabile, need it now. There is no ‘later’.
For us, efficiency is greatly dependent on eliminating, or at least greatly reducing, the demand that plugins pull when not in use. Melda’s example might be useful for some manufacturers, who create significant time load when active, but are resting.
Interesting. I haven’t used Melda other than some promotional effect that I got for free. There was nothing that made me want to replace Amplitube. Though now I know how much of a resource hog it is…
I was actually thinking about trying to hack in a binding that would turn the effects chain on and off. But I don"t know if the effects would turn on fast enough. Does Cantabile even have signal detection? I originally thought about using key press/release, but that doesn’t account for sustain pedal, reverb, etc.
For sure live play is not a priority for a lot of these developers. I can often tell by a quick look at their youtube walkthroughs. If the whole discussion is about making sequences or (ugh) all the pre-built patterns, their walk through quickly becomes walk away.
I wish I understood what exactly VSTs are doing when they incur huge time-loads without increasing CPU load and without accessing disk. They’re not computing anything, since none of my cores are above about 6%. Windows Performance Analyzer says nothing is accessing disk or network. It’s not audio driver latency because the time-load goes massively up depending on how many notes I’m playing, which shouldn’t really affect the audio drivers.
What’s left? I suppose it could be memory access latency, but when I made the move from DDR4 to DDR5, I didn’t see much change. So I don’t think it’s dominated by memory latency. What could those VSTs be doing?
Once upon a time I did a deep dive into the Windows Performance Analyzer toolkit to try and figure out what exactly is producing certain delays, and I found some surprising things. WPA is hard to use, but in some cases I discovered that another process (a low-level driver that can’t simply be uninstalled) was acquiring a lock deep within the .NET subsystem, which made other processes using .NET wait. This makes me worry that Cantabile’s increasing reliance on .NET for things like binding expressions might have some unwanted performance impacts.
Hi Kevin
For sure, the time load can increase when more notes are introduced.
It’s the time it takes for the ASIO buffer to process the demand. When you play, you introduce more demand.
Much of this discussion has focused on why some plugins seem to be so busy when there’s no input. It’s just because, in their particular case, they’re ready to deliver when you make that demand.
Whether each plugin author has optimized this aspect of operation is something we can’t know.
As was suggested previously, some plugins may not like ‘waking up’.
The ASIO driver is very important in this partnership. A good ASIO driver is a low latency performer, and may do the work a less capable driver chokes on.
I understand how important ASIO driver efficiency is for decreasing overall time-load (when non-silent), but I don’t understand why ASIO driver efficiency would have anything to do with the number of notes being played. As far as I know, ASIO drivers receive buffers of sample bytes, and the buffer sizes and rate of delivery to the driver are fixed (except when you change your audio engine settings or there’s complete silence). Based on my testing, playing more notes does not increase ASIO driver overhead. The drivers keep getting the same size buffers at the same rate no matter how many “notes” were used to construct the buffers they receive.
However, playing more notes does increase the time it takes a VST plugin to generate the buffers. Therefore, when we see time-load increase due to playing more notes, it’s primarily because our plugins are under higher demand, not our ASIO drivers. Am I incorrect?
The mystery to me is what those slowed plugins are actually doing when they face higher note loads. It would make sense if the increased demand made them struggle to compute the buffer content in time (CPU load), but that should presumably raise the load of at least one CPU core to some high level, which is not what I ever observe. It would also make sense if it caused plugins to load more from disk, but I’ve ruled that out too (no disk accesses at all during my high time-loads). If I understood what they spent so much time doing, that might suggest how to improve my hardware/software to address the bottleneck.
That’s an interesting observation. Have you not experienced clicks when the time load consistently exceeds the max? And if you test with a real hog, something like an omnisphere multi or a really heavy Sines patch, you don’t see time load increase with demand?
I’ve never not seen that correlation.
