We hade a bug report that our RTAS plugin didn’t work reliably in ProTools, giving the infamous 6101 error - even at large block sizes.
The problem occurred on an 8 core Mac Pro System, and we werent’t able to reproduce it on a CoreDuo Whitebook.
But the errors showed up as soon as we tested it in ProTools 9.0.5 on a i5 Macbook Pro, though only if we were using strict settings for the Playback Engine (64 samples buffer size, report errors when cpu sage hits 40%). We did a quite a few builds with different part of the plugin enabled and had some stunning results:
- the error message often came up at the same time where an overload indicator in the gui was repainted
- the plugin runs stable if the plugin GUI is never opened
- the plugin runs mostly stable if the ::processNextBlock() of the plugin is totally disabled, but the GUI is opened and rapidly repainted with random values
So that looked like some concurrency issue with the audio and gui thread, so I carefully stepped through every single line within the audio callback to check if I missed a lock, allocation or change-message.
In the end it turned out changeing one line that looked harmless to me made the big difference:
replacing Time::getApproximateMillisecondCounter() with Time::getMillisecondCounter()
What’s going on here? Isn’t the Approximate variant the one that is supposed to return immediately with a somewhat outdated version of the counter? Can anyone give me a reasonable explanation for this? Especially on why this call doesn’t do any bad if the plugin editor is closed.