Yes humphrey, that’s what I was trying to say in my last paragraph. Thanks for making it clear.
Ah, sorry, my bad - didn‘t get it.
I remember I had a longer conversation on this issue with brad. Finally we ended up with the fact that there was no possibility to fix this from inside cantabile as load balancing obviously is something happening deep inside windows os.
But at least I was really happy brad made „engine restart“ destination available in bindings. Similar as you I had this mapped to a control button on my masterkeyboard.
Meanwhile I substituted it by a binding restarting engine on song load which is available in each song. Depending on the load I observe I decide to enable/disable these binding individually for each song. The binding of the control button is still available in case of troubles.
Regards, humphrey
Further checking with Windows Task Manager shows that until I start nectar 3 all 4 CPU cores are sharing the load. When I start nectar 3, CPU core 2 shoots up. The others stay the same. When I stop/start the engine, the load is redistributed correctly. So all is OK until a certain stage is reached and then the load is added just to 1 core 
A further observation:
If I load a song with Cantabile already running the CPU cores are not balanced and again core 2 takes most of the load (unless engine restarted). Time Load around 100%.
If I start Cantabile with the song (e.g. reload the last used song at startup), the CPU cores are balanced. Time Load around 50%.
That’s interesting. I think I may have missed that point (or my brain failed to register it). Let me think about this some more…
… maybe it was not a receiver but a sender-problem (I’m not always clear enough when I describe issues)… 
Could anyone having this issue please try build 3584 and let me know if it makes any difference.
Also, have a play with the new option -> Audio Engine -> Thread Affinity Mode -> Disabled/Preferred/Forced and let me know if that makes any difference.
For details about these options, see this post.
Explanation:
From what’s been described above it seems as though Windows is scheduling some of Cantabile’s core audio threads to run on the same processor core. I’ve personally never seen this, but that’s sure what it sounds like.
In an attempt to solve this, Cantabile can now specify “this thread” should run on “this processor” via the Thread Affinity mode options. See the above linked post for more about the different affinity modes - but basically either “Preferred” or “Forces” should (hopefully) resolve the issue.
Brad
Preferred=no difference on my system.
Forced=issue still there but Time Load reduced by 10-15% in all scenarios. Sometimes as much as 20% less! Got to be good. CPU core #1 is now the one taking the extra load. Engine restart still redistributes the load as before.
So it has helped but not solved the issue yet.
Thanks a lot for your work on this. It is much appreciated!
Guessing here, but this sounds to me like Cantabile’s audio threads are getting redistributed to other CPU cores, but perhaps threading in some of the plugins you’re using aren’t?
This is baffling to me - Windows is usually really good a distributing load over processors. I wonder why it’s decided to load up one CPU in preference to the others in your case?
Brad
Hi Brad,
even though I can easily live with the option to restart engine I‘m just curious about the story behind.
First off: when we talk about one core taking the whole load I have to say: this is a guess derived from observations I made in windows ressource manager. It‘s not strictly one core having 100% and the others zero but more a massively disbalanced distribution with one core running around 100% and the rest doing something. This clearly leads to a mismatch between cpu time (displayed in cantabile) and average cpu load (displayed in task manager) which is not surprising.
I don‘t know what is responsible for distribution but what I meant to have learned from what you mentioned windows is doing it. If this is true and if windows is „triggered“ to redistribute loads by restarting audio engine I totally agree: windows is doing a pretty good job here. I don‘t remember a single case where audio engine was restarted and cpu time was still high. This works perfectly and is absolutely reliable.
So, what are the situations when overload szenarios happen (at least for me)?
- It always needs quite some plugins in a song to make it happen. Never had this happen on a single plugin.
- It needs quite some cpu consumption to be focussed on this. It feels like this could be a psychological issue: a user having bad cpu balance resulting in a value of 30% probably doesn‘t care about possiblities to reduce load, a user having a value of 90% most probably does.
- I can reproducably „create“ overload scenarios that can be „fixed“ by restarting engine by stacking heavy load plugins one by one. For some reason windows doesn‘t seem to notice that redistribution would be necessary.
- I can create overload scenarios in a heavy load song which was optimized by restarting engine before by de- and the re-activating the plugs.
- I can also „create“ overload scenarios by having lots of plugins preloaded in a setlist. Here it seems that calling up a new song doesn‘t force windows to do a redustribution - is this due to the fact the plugin isn‘t really loaded but only activated at this moment? Even if I restart engine by hand and store this song this is not remembered when loading the setlist next time.
Don‘t know if this is helpful to get the clue behind. If I can be of any help don‘t hesitate to contact me.
Regards, humphrey 
1 Like
Have you tried build 3584?
Not yet, I‘ll give it a try this evening when back from the job.
@brad, I would say that the issue for all scenarios is solved except for when I start up Cantabile without any plugins running. It seems like Windows has decided the load is too small to be apportioned to more than 1 cpu core. When the load increases with more plugins started it stubbornly sticks to mostly the one core. Engine restart cures this.
Starting Cantabile with plugins running is OK. But if I then stop the plugins from running and then start them again the issue returns.
So it seems like it’s something to do with the response to starting/stopping the plugins running.
So to sum up, everything will be OK for live use. You load a song it’s fine. In the studio, you can select your plugins and do your editing on the understanding that the load balance may be upset. Either restart the engine or just save and reload your work and you’re good to go 
1 Like
Hi,
So if you start with a set list preload that loads some meaty plugins, that solves the issue?
1 Like
Hi there,
just gave 3585 a try with no expectation as the first results of x2zero didn‘t sound promising. So I was really buffled to see that preferred mode seems to do the trick here.
The first tests were done with songs being typically „misbehaving“ concerning load balancing.
So I decided to try it with a larger setlist (about 55 songs and automatic engine restart disabled in each). Also here: no problems any more.
I don‘t say it‘s finally fixed (not enough testing here to shout it out loud) and I‘m at the end of a long journey, but: this looks damn good!
Once again: great job and many thanks to Brad for revisiting this issue,
kind regards, humphrey 
2 Likes
Excellent. Really pleased to hear this.
Just to clarify a couple of things mentioned in comments above. In theory Windows can schedule a thread to any CPU core every time it’s scheduled to run. For the audio threads that basically means every audio cycle Windows should pick a CPU core for it and let it run. In theory if some cores are busy Windows should pick another one that’s not.
What seems to be happening here is Windows is internally setting a preferred core for some of the audio threads. It makes sense to try and keep threads on the same CPU core since that can improve cache hits but that’s not what we want here. We really want all the audio threads running on different cores.
It seems in the situations described above that Windows is putting all the audio threads on one core - why that is who knows? It could be the other cores were busy at the time the audio engine started (perhaps plugins doing background sample loading on those cores for example). Then, when the audio engine is restarted, Windows does a better job of setting the preferred cores for the engine’s audio threads.
What I’m trying to say here is that in theory, Windows should be able to re-balance which cores each thread is running on dynamically - it shouldn’t require restarting the audio engine to make that happen - but it seems in some cases it does.
Anyway, both the Preferred and and Forced options instruct Windows to explicitly put each audio thread on a specific core… and it seems at least in some cases this is working.
For the technically minded, Preferred calls the Windows API SetThreadIdealProcessor and Forced calls SetThreadAffinityMask(with one bit set).
Brad
3 Likes
Thanks for the explanation @brad , I think I’ll do some checking on my rig with this new information in mind. Thanks to all the posters and testers on this point of issue. I think this is an important thing that has been analysed and addressed and it has also become an improvement.
Dave
1 Like
Spit it out Brad !! 
That leaves me out. 
1 Like
At least I tried to sound smart 
1 Like
Yes you did. I just didn’t feel the smartness after I read that. I stopped at smart-ASS. 
1 Like