I’ve never actually seen this on any of my test machines, so I’m only going on what I’ve heard from others. My suspicion here is that for some reason on first start of the audio engine Windows ties the audio threads to a sub-optimal set of processor cores and on the second restart selects a better set.
The first thing to try would be Options -> Audio Engine -> Thread Affinity Mode -> Forced.
If that doesn’t help, it’d be worth grabbing one of those CPU monitoring tools and look for things like CPU clock throttling or CPU parking. In particular look for differences between before and after restarting the engine.
as I din‘t have the same plugs available I just loaded a large setlist with 62 plugs in it, quite some cpu hogs like Omni, Diva, Serum, Viper but also NI Session Horns Pro and Session Strings Pro 2 were involved.
I tried to figure out if cpu meter shows different behaviour after a hard stop and restart of the audio engine. Even though it is hatd to tell sometimes (you know there‘s always some deviation going on) I‘m pretty sure that effects stay beyond 5% if there is really an effect (for me I‘d say there is non).
Maybe one aspect to take note: I always useaudio engine in agressive mode - maybe this makes a different.
Sorry to be not that helpful. Should there be additional tests where I can help out just tell me.
I have been trying out your suggestions and found that “forced” and “aggressive” cpu switches didn’t change things as far as the initial load value after a pre-load of a set list. I ran a CPU monitor and the CPU parking is and was disabled so that box is checked. The load balance seemed to lean to more use (idling at 10% load) on the 1st and 4th cores and less (About 5% load) on the 2 and 3 cores. What I am doing that does correct the load balance is a 2 binding group that does an Engine reset after the song is fully loaded and after a short delay.
My rig didn’t liked a delayed reset with a single binding like this and crashed. It’s likely a no-no with my setups drivers or something, I’m not sure but by making sure the song loads fully (I figured the transport wouldn’t start till it was) and then doing the reset it works fine.
Thanks again to both of you for chiming in, I will stick with my current solution for now, I put it in the a first startup song in the set list and only run it once at the beginning of the show. It holds it’s load values after that till I’m done.
I came across this some time last year when we had another computer config discussion:
Interesting enough, I ran Cantabile on 4 machines; the problem only occurred on two of them.
@brad promised to run some tests on this at the time, but apparently nothing conclusive came from that - I imagine it’s pretty difficult when you can’t reproduce the issue…
I just tested the scenario again on my studio PC - now the time load stays stubbornly at around 35%, now matter how often I restart the audio engine.
And TBH, I think that this 35% is a fair representation of the CPU load - maybe the reduction in time load was a reporting / measuring issue? It doesn’t really make sense that my (weaker) old live laptop should run the performance test song at far lower time load than my newer one after engine restart.
While I haven’t taken the time to do scientific tests, I have noticed similar behavior - pre-loading a set list full of hefty plugins, and having the Time Load run what seems to be 20-30% higher than expected. Stopping and starting the audio engine seems to help.
@Torsten, I don’t have any conclusions, but it “feels like” a power problem. When I’ve had this happen (before restarting), one of my heavier-layered songs got auditable crunchiness (distortion) and usage went over 100%. I did the on/off trick and usage went way down and the crunchiness went away. It seems like the measurement in that case was correct. This was on my live DeskMini with Core i5 cpu.
I had the same experience as @RackedBrain two days ago. After switching thru a few different songs, I heard some crackling sound and saw that the cpu meter was over 100%. I turned the engine off and on again and cpu usage dropped and sound returned to normal.
I’ve been thinking about this more overnight and I’d really like to try to get to the bottom of this, but since I can’t reproduce it here if you’ve got time to run a couple of tests for me, that’d be great.
Firstly, could you capture a profiler log of this:
Start Cantabile in a state where it’s in high-load state.
Let it run for about 5 seconds or so
Restart the audio engine and confirm it’s switched to low-load state
Let it run for another 5 seconds or so.
From View menu, open the Profiler
Click the menu in top right and choose save.
Send me a copy of the saved profile log.
Also, I’m wondering if this might be related to Cantabile’s multi-core thread pool and whether disabling that changes the behaviour:
Start Cantabile and go to Tools -> Options -> Audio Engine -> Number of Audio Threads -> 1 (disable multi-core support).
Shutdown and restart Cantabile
Take note of the load percentage and then restart the audio engine.
Let me know if the same drop in load happens after restarting the engine when in single core mode.
I made 2 profiles using your instructions, one using automatic 4 core and the other using single core. The 4 core profile showed a reduction in load on a restart whereas the single core didn’t look like it changed to me. No notes were played or any load added by any Leslie switching so it was at idle load for the tests. Thanks for looking at it and I hope maybe this will help
OK, thanks for that. That seems to point towards this being related to the audio thread pool, which kinda makes sense. Leave it with me, but since I don’t want to make any risky changes in the current release series, I might revisit that area for this TechUpdate work I’m doing and see if I can improve things.
