On Cantabile Performer 4171 (Win11 x64), if I merely open Tools → Options and then cancel out of the settings window without touching anything, I get a massive performance improvement for the remainder of my Cantabile session (until I close and restart Cantabile). Does this happen for anyone else?
(In case it matters, my audio interface is an Antelope Zen Go TB3 with the latest ASIO drivers and firmware.)
Background: I’ve been struggling with performance issues since upgrading to 4171, but assumed I was simply exceeding the limits of my hardware. But then today I chanced upon the following strange workaround, which for me is 100% reproducible:
Start Cantabile (no song loaded)
load cpu-heavy song file
play big chords with the Profiler running [Result: time-load regularly exceeds 105% (audio glitches)]
Either close and re-open Cantabile, or clear the current song using New Song (no song loaded)
Open Tools → Options and cancel out of Options without changing anything [the audio engine resets],
load same song
play big chords with Profiler [Result: time-load never exceeds 33%(!)]
Does Cantabile do something when resetting the audio engine at Options-exit that it doesn’t do at startup that could explain this?
Looks like the infamous “engine-cycle phenomenon”. It’s been around for years, and nobody (including @brad) has really gotten to the bottom of it.
This happens consistently on some systems, others aren’t affected at all. For those systems that are, a “cycling” of the audio engine (turning it off and on again) reduces the time load significantly. No need to go to settings - try simply using the “power switch” button. There’s even a binding target for cycling the audio engine.
It seems this forces the audio engine to re-allocate processes to cores and threads - at least this is the dominant hypothesis out of previous discussions…
I experienced the same performance issue beginning with build 4161.
Using the method @Torsten suggested, I added an Engine / Application Start binding in the background rack to restart the audio engine every time I start Cantabile.
I believe there is still an audio engine bug in builds 4161 and later, with the way it allocates processes to cores and threads on startup. @Brad will probably find it and fix it eventually.
Wow, this is such a significant change to me. Is there a reason that despite being “around for years”, this isn’t advertised more? Even after reading “glitch-free audio” backwards and forwards, and trying every tip on every list I can find about Windows realtime audio performance, this is by far the most effective tweak I’ve ever tried. I wonder how many more users might be able to use Cantabile on their hardware if only they knew about it.
Surely it must be a bug in Cantabile’s start-up code? I think I’ve probably always been affected by it to some degree, but I think it got much worse for me with newer versions. Could it be diagnosed by dumping some data about audio engine thread allocation before and after engine restart on an affected system? I’m willing to do that if someone tells me how.
Might be more than just an issue at startup. I’ve had to cycle the audio engine again when the load creeps up after playing a while. In fact, just now i noticed the load getting large while Cantabile is just sitting idle:
Start Cantabile (preloads song and racks) → 70% load
Cycle engine → 30% load
Play keyboards a bit → 40% load (though i’ve seen it go much higher)
Cycle engine → 30% load
Leave song up and come back a half-hour later → 70% load !!!
And as @Torsten mentioned, it seems to only happen on some systems — in my case, my old desktop running Windows 7.
Just to confirm, this is a known phenomenon that I’ve never got to the bottom of.
As best I can tell it’s related to audo thread to core allocation/affinity which is almost entirely managed by Windows. Cantabile does have one option you can use to try and tweak this: Options → Audio Engine → Thread Affinity Mode of which there are three options:
Disabled - leaves it to the Windows scheduler to run audio threads on whichever processor core it likes
Preferred - tells windows that each audio thread should prefer to run on a particular physical processor
Forced - tells windows that audio audio thread must run on a particular physical processor.
(by physical processor I mean CPU core - as opposed to CPU “thread”)
The default mode is Preferred, but you might get better results with either of the others.
One thing I’ve never investigated (and maybe someone here has some insight) are CPUs with both performance and efficiency cores. I would imagine that choosing forced affinity mode, where that results in an audio thread running on an efficiency core wouldn’t be great.
I have been doing the work around for quite a while but have lately experimenting with a new idea that wasn’t available till recent binding additions. I found that some VSTi plugins were appearing to me to be involved when it occurred, in my case IK Multimedia B-3X and Tracks Leslie. Also UVI Workstation running Ravenscroft or AS B5. As a result I could play a few songs that didn’t have trouble and didn’t have those plugins loaded in the songs but as soon as I loaded one with one of those the load would jump higher than it should have. I did manual engine restarts when I saw it and even tried restarting the engine as part of all songs that had those plugs but went back to manual. I came up with this binding that uses an expression to test the load at Song load and if it is higher than the expression is set the engine restart occurs. Might help others so I thought I’d introduce it here.
I experimented with the Thread Affinity Mode setting. Here are some observations:
For me, “Disabled” and “Preferred” show no observable difference.
“Forced” is markedly better than the others without restarting the engine. It gives me about 50% peak time-load on loads that otherwise exceed 100%. After restarting the engine, “Forced” becomes even slightly better—around 45% peak time-load.
But starting up with “Disabled” or “Preferred” and then restarting the engine is the best. It gives me around 33% peak time-load.
Unlike @JimboKeys, I haven’t observed any discernible load-creep. Manually restarting the audio engine massively improves my performance for as long as Cantabile stays running.
It doesn’t seem to matter when I restart the engine—I can do it immediately after Cantabile starts up with no song loaded and it works like magic. But closing and re-opening Cantabile reverts it back to poor performance until I restart the engine again.
Question: Is there any way I can discover and report to you what the core allocation is before and after engine restart? Maybe that info would help reveal what’s really going on.
Having read of this thread, and still chugging along on 4061, I can confirm this
works also, I’m using intels K series cpu i5 2500K (i have an i7 to put in when I get around to it)
before reading this thread, for a song I am working on right now, it had a peak load of 82%
it now peaks at 61% that was just by cycling the audio. in preferred mode
Edit: trying the forced mode had a brief peak of 190%
Having it in disabled mode peak load was 60%
I have noticed that I get performance overload problems with Korg MODSTATE and WAVESTATE native if they have been running for a long time, and would love a way of resetting them when I select a song if needed, but when I have tried an engine restart it ad no effect
The other I noticed is all you need to do is select another patch and step back to the selected one to clear it, so are there a few bindings that allow you to do that?
It is the plugin in preset I change when I see the issue, albeit I am using the Cantabile preset model (and I haven’t thought of trying to change that)
It’s not a biggie and so far (touch wood) only occurred in the studio when I might have a song selected for a long time whilst tweaking.
As it is unique to two Korg Native plug ins, I am assuming it is a plugin issue
I did in the beginning and it worked but I decided after working with it a bit that I only needed to perform the Engine Restart on songs with B-3X or AS B5. My best guess, because I really don’t have the proof, is that the Leslie emulators in both plugins has something to do with it. So I located the binding only in the Songs where those plugins are as well as on the startup song I made that acts as an unloaded song/landing pad with low time load that lets me gauge how the session is loaded before I pick my first song. Anyway, that’s why I posted it that way.
in preferred mode