I’ve posted a problem concerning CPU load balancing about a year ago but unfortunately never got a proper solution:
when using multiple instances of the same plugin, agressive mode is a proper way to reduce cpu load. Latest example: NI Symphony Series String Endamble. Arranging 4 instances of kontakt (violins, violas, celli, basses) inside a rack makes a good string ensamble available for live use.
The problem: when calling up this rack cpu loads of 100% and more maxing out the cpu and of course leading to crackles (agressive mode active). A quick look into task manager shows the reason: all instances share the same cpu core!
What I found meanwhile: restarting the engine in agressive mode forces cantabile to use all cpu cores resulting in a maximum cpu load of about 35-40% even when using auto divisi, portamento,…
As I don’t expext a solution inside cantabile in near future my idea is to restart the engine a short time after a song using the strings rack was loaded by using a binding.
Unfortunately every attempt led to a process restarting the engine again and again in cycles (f.e.: source: song - on load -> target: engine - restart). Even a delay didn’t get me rid of the behavior. Obviously the restart process also restarts the binding, restarting the engine,…
So: I’d be very happy for any idea on this workaround.
Restarting the engine via a binding is a catch-22 because of the issue you describe. The only thing I can think of here would be to put the engine restart on a particular state, and advance to the next state before restarting the engine. No idea if this will work, but perhaps a possible work around for you.
As for the actual underlying problem, I can’t think of any reason why Cantabile would run the plugins differently after restarting the engine like this. Are you sure you’re running Windows in high-performance mode and don’t have core parking or other power saving features turned on? Basically this is all scheduled by Windows - Cantabile just creates enough worker threads for each core and lets Windows decide which threads run on which core. I’ve never heard of it loading one CPU and leaving others unloaded - except in power saving modes.
thanks for your quick replies. Short before midnight here, so I can’t do more tests for today, but will be back tomorrow, send detailed information and of course check out the work around.
What I can tell for the moment:
Definitely running in high performance mode
There should not be any energy saving functions activated
Core parking: not sure where I could get access to this feature (bios?) but will have a look on this. Don’t really think this could be the reason as the same effect occours on 2 different PCs with different OS…
Turnig mutiproc mode off in c3 while active in k5: i’ll give it a try. But please keep in mind that the same effect is reproducable with other cpu hogs like serum (and here we don’t have a sub-host kontakt)
I also tested serum (Symphony Series tests to come - purchased it yesterday) in Cubase: Cubase was able to do a proper load balancing.
I understand the problem I describe is not important for every user and I agree: using 4 instanes of diva or serum is not the daily business. In case of orchster libraries I see it slightly different and the fact I can force c3 into low cpu consumption shows me that c3 is able to handle such heavy loads.
just restarted the machine as core parking drove me nuts: found the corresponding entries in regedit. Core parkinig was not disabled but the percentage of not parked cores were already set to 100% in the energy settings.
I changed core parking settings in regedit to “0” and tested again without a different result.
A small additional info: I’m sufficiently able to force c3 back into the high load mode by shortly suspending the rack with the 4 kontakt instances inside.
as promised an update: I just sent an mail to Brad with a small attached video showing decrease of cpu load after engine restart and increase after suspension / re-running the rack (sorry, but I was not able to upload it here).
@Ade tried your hint with internal balancing of kontakt / disabled multi-proc support in c3 (and also vice versa) but with no positive effect.
Next will be to try the workaround Brad described.
I too often restart the audio engine after loading a new, ‘heavy’ song for the same reasons: there is a definite rebalancing of the cpu load.
I remember that Brad, you added a small delay during the restart to help out someone with an audio interface that wasn’t behaving. Mine never had the problem and now that delay is causing an issue with my live setup.
I have a rack that we use for chatting between songs. I use that chatting time to do pre-flight checks and reset the audio engine. I’d ideally like the time the audio system was down to be an absolute minimum.
Brad, could you add the delay as on option, even in the settings file would be great?
Thanks,
Neil
obviously its the same aspect that treats me to reset the engine from time to time. Of course I see your point and strongly support it.
@brad: I reported the load balancing thing months ago, providing descriptions and even a small video clip showing the problem. I also tried to use the workarounds that were mentioned with the result of freeze and lots of crashes. So I had to go the way Neil described.
You promised to have a look on this after finalising some tasks you were busy those days. So I kindly ask: would it be possible now?
Another idea (kind of workaround): it seems that a short stop/start of the engine is sufficiently able to do a proper cpu balancing. Would it be possible to add an attribute to a song/state (additionally checkbox) to automatically stop/start the engine after song load (maybe with adjustible off-time) if needed? So the restart would become part of the song and would only be iniziated if necessary.
To be clear: I definitely understand that many users don’t have these problems, specially when using light weight plugs. In my case its orchester libraries and the like using lots of cou power and the solution to have an optimized cpu balancing seems very attractive in comparision to buying a new high end laptop.
I did look into the problems reported by @humphrey but couldn’t reproduce the problem and then probably got distracted and never got back to it. Sorry about that, it shouldn’t have slipped through the cracks like that - I’ll log it and try to carve out some time to investigate.
The point I did get to when I was looking into it though was that I couldn’t find anything in Cantabile’s audio engine that would improve performance by a restart. I double checked a whole lot of things to make sure there were extraneous objects left around processing when they shouldn’t be and was pretty sure everything was in good shape.
So… my suspicion at this stage is this is related to the audio driver or something else in the system but can’t confirm that yet.
As for the delay on engine restart - it only does that after a system power resume so wouldn’t help in this case and won’t be causing any slow down of a normal engine restart.
This would be a bit of a hack which I’m not sure I wan’t to introduce as an explicit option. One idea would be to use the Song Long trigger to invoke the Restart Engine binding, but this is currently broken because it gets into an infinite loop where restarting the engine causes the song load trigger to re-fire. If I was to fix that would that suffice for now?
thanks alot for your response. I understand your point not to implement a hack and sure: if the “never ending story” could be stopped everthing should be fine. It’d set me into the position to decide for which song a reset of the engine is necessary.
I’ve just put up a new experimental build 3246 that includes some changes for this:
Restart Engine bindings has been renamed to Restart Engine (Full)
A new binding “Restart Engine (Quick)” that restarts just the core audio engine and not the higher level objects like songs and racks etc… Basically this restarts the audio driver, MIDI devices and the core engine itself (multi-core execution engine, worker threads etc…)
Restart Engine (Full) no longer fires song/rack load/unload trigger bindings so it can now be safely used in song load binding.
This is all fairly experimental so give it a go and let me know.
@humphrey - I’d be very interested to hear if the Restart Engine (Quick) binding works for you to reset performance issues.
A quick response: just implemented the “quick” binding version into every songs of an existing setlist (no binding delay necessary). It seems that load balancing is now working from start as I was not able to generate a decrease in cpu consumtion by restarting engine by hand any more.
I’ll send some more information when more tests are done (I’ll do some heavy load scenarios for this).
I set up a small setlist with 2 songs in it: one with 4 instances of DIVA (devine mode) the other with 4 instances of SERUM (pad sounds with lots oscillators inside).
Loading each of these songs from scratch gets me to massive cpu overloads easily (agressive mode active).
After implementing the quick engine reset in each song cpu is far beyond 100% right from the beginning (no need to do an initial reset by hand or the like).
I will go on with some tests but as it seems, this is the perfect fix. Best of all: as the quick-version seems to do the trick I get no noticable additional delay when switching from song to song.
Things looking good here too. Quick start is a piece quicker and leaves the engine down for a fraction of a second. The full restart takes media players down, but the quick leaves them intact. I could get away with a quick restart mid-song if need be.
I premised to do some more testing:
I setup several setlists with (partially) heavy load and everything fine and stable. I always got a massive decrease in heavy load scenarios with the quick version of engine restart. Since I prepared all of my songs with respective bindins (Song/load -> Engine restart/quick). Additional delay (switching time) is not really noticable for me.
One additional observation: when I asked Brad for support, I handled Engine in aggressive mode due to the fact I had several identical plugs in use in parallel. Meanwhile I managed to only have one plugin of a kind in one song. So I gave compatible mode a try. I was surprised to see the same decrease in cpu use when implementing the mentioned binding - no need anymore for agressive mode here. As I don’t think this is a speciallity of my system I thought I should mention this - up to 30% decrease for free may be interesting for other users too…
I am reviving this thread because of the behaviors I am experiencing on my performance rigs. I preload some hungry plugs and when the set-list finishes loading and loads Song one on the list the load value is on average about 30% higher than it would be if I did an engine reset before playing anything. On my rig while running Ivory, B-3X and MODO bass with a single reverb buss running Eventide ultra reverb that would be around 70 to 75% but after the engine reset it settles at about 40 to 45% so it is a great load reduction and gives the load headroom needed for B-3X Leslie speed ramping. I tried using Song on load bindings to do a restart after the first song was loaded but it executed before the song was fully loaded and crashed C♪3. I ended up having to use delayed engine restarts after the song was fully loaded. I was wondering what or if anyone else was still using engine restarts to help with load problems and how they do it. Also since I think I am not the only person having these results if there could be a way to address it that was part of the preload sequence and was carried out as the last instruction once the first song was loaded. I have noted that in my case doing the engine restart once corrects the load value and it holds till I shut down. Anyway, if you have something you would like to share please do so. And if you can @brad your observations would be great.
as I was the origin of the thread here
my observation on this: I remember the first step was an implementation by brad that enabled a forced restart of the engine. This really solved the problem even though introducing a noticeable delay when calling a new song.
Next step was a different implementation around load balancing in cantabile. After some intense testing I found that brad had done a splendid job (as usual ) so restart became obsolste (at least for me) and this lasts till now. So no problems here so far (but who knows?).
I will happily do some tests on heavy load scenarios and report back here (maybe tomorrow).
) so restart became obsolste (at least for me) and this lasts till now. So no problems here so far (but who knows?).