Temporary Freezes on v4197-4201

Starting a new thread for this issue, since I can’t seem to nail it down and I’m hoping @brad or someone else has some insight/advice on how to diagnose it…

On Performer v4197-4201 I get rare freezes/pauses during which Cantabile becomes unresponsive for about 10 seconds or more. During the freeze, either no sound plays or any sound that was playing at the time of the freeze stutters for a few seconds and then cuts out until the freeze is over. Cantabile’s UI remains unresponsive throughout (I see the blue ring instead of an arrow for my mouse cursor when it’s over the Cantabile window), though I can interact with the Windows desktop, task manager, other apps, etc.

Once the freeze is over, everything mostly works again, though some plugins seem unwell and unable to fully recover. For example, they have stuck notes or the sustain pedal polarity is reversed or something. To fix these problems, I must completely close and restart Cantabile.

The bug is rare and I can’t find any particular trigger. It will happen maybe once for no apparent reason in a 3-hour practice, or not at all. Today it happened while I was playing a Kontakt 7 piano, no media file was playing, and the transport was not playing. I’m not sure whether Kontakt 7 has anything to do with it, but I usually do have a Kontakt piano running (even if I’m not actively playing it), and I know @brad was battling a Kontakt-related bug recently, so maybe that’s a lead.

Nothing interesting appears in the log file (but I haven’t managed to experience it while verbose logging was enabled), and there are no crash files, so I’m not sure how to get more info about it. I’ve experienced it on every version from v4197-4201 but never on any version before those, so it seems like a new issue.

Any ideas?

–Kevin

I’m on 4199 and haven’t noticed any freezing. Even with Kontakt 7 playing Production Voices pianos.

Hi Kevin,

I can’t think of anything in that build range that might have introduced issues like this (at least nothing that wasn’t fixed by 4201).

Are you sure this is related to those builds. Have you tried reverting to 4196 to confirm.

Of the changes in that build range, if anything it would be the change/bug/regression related to bindings that’s most like the culprit - so consider what bindings were being triggered at the time it freezes.

The other thing worth looking at next time it happens is the profiler window (View → Profiler). I’d be curious to see how it reports the delay and if its associated with a particular plugin or some other processing item. If you’re going to do a long practice session might even be worth bumping up the profiler detail level (Tools → Options → Diagnostics → Audio Engine Profiling → Detail Level → Detailed). Either way, next time this happens, bring up the profiler, save the profile and send me a copy to check out.

Sorry I don’t have a better immediate answer.

Brad

Thanks, brad. That’s useful info. I’ll check the profiler next time it happens.

So far when I’ve reverted to 4196 the problem has disappeared, and when I go back to 4201 (to fix fractional tempos) eventually I see it again. But I’ve admittedly spent more time on 4201 than 4196, so my sample is biased.

The complete freeze of the UI combined with the effect on the audio thread seems interesting. The binding loop bug never froze my UI or stopped my audio — I could interact with the UI during the loop and see the binding firing — so this feels different. And I assume that if a plugin’s audio processing became unresponsive, that shouldn’t freeze the UI thread, right? (I always have Cantabile’s multithreading on “Aggressive”, btw.)

Is it possible that something in the new MTC code could be amiss? For example, could a rounding error or integer overflow bug in Cantabile’s timekeeping cause it to accidentally wait a long time or start believing in time-travel?

Unlikely especially if you don’t have any output devices enabled for MTC - in that case the MTC generator code isn’t running anyway.

I indeed haven’t done anything with MTC. So unless that change involved improvements to general timekeeping, I guess that rules that out. I’ll have to keep searching. Thanks!

Happened again tonight. Here’s the profiler report:

As you can see, it’s blaming the freeze on two plugins: one Omnisphere instance and one Kontakt 7 instance. The Omnisphere instance wasn’t playing anything at the time. The Kontakt 7 instance was playing an instrument from Cloud Supply.

I think I’ve only ever seen the bug while Kontakt 7 is playing something, so maybe that’s a lead. But I think it must be something new to Cantabile 4197 and later because this particular rack is one I’ve used hundreds of times prior to 4197 and never saw any problems, and so far I’ve never seen it when I downgrade to 4196 or earlier.

–Kevin

Update for @brad:

After disappearing for a while, this problem happened again four times today (on Performer 4203 x64) – once during a live performance, sadly. All four times were during the same song, which uses Kontakt Cloud Supply again. So far I’ve only ever seen this bug while running Kontakt, and especially often with Cloud Supply.

Instead of completely freezing Cantabile, several of today’s occurrences ramped the CPU load to high levels on all performance cores within a few seconds time, and stayed there even after I stopped playing for several seconds, until finally returning to normal (whereupon I could play again without stutters and crackles). When this happened during the live show, I quickly killed and restarted the audio thread with Cantabile’s power button, which immediately fixed the problem.

Tonight I played the problem song over and over again for an hour (for science!), and got it to recur once. But this time Cantabile completely froze, and then when it came back the audio thread seemed to be dead. Profiler looked like this (yet the Cantabile power button was still green):

There was no sound afterward until I clicked Cantabile’s power button from green to red and back to green again.

–Kevin

Hi @Hamlen

Sorry to hear you’re still having this issue. You didn’t by any chance keep the log.txt file from one of these problem runs did you?

If not, and you have to try to reproduce it, it would be worth in Tools → Options → Diagnostics turning on verbose logging and also setting the profiler detail level to either 2 or 3.

Brad

Caught it tonight with Verbose Logging enabled and Profiler set to 3. Log file and profiler pic sent.

–Kevin