AAX audiosuite timer callbacks


I’m working on the Audio Suite version of an AAX plug-in on Windows. With this set-up I have noticed that, when processing audio, juce timers fail to update at all, which I’ve tracked down to no longer receiving any calls to messageWndProc whilst the AudioSuite is processing. I’m not sure if this is expected behaviour for timer callbacks or not, but I thought I would bring it up in case we’re seeing something that is actually a problem for people.

Any thoughts?


Well, that’s really not within our control from the plugin’s side of things… If the host is stopping the message queue, then timers and other kinds of message won’t have a chance to run. I guess that if you have some work to do, you’d need to kick-off a thread to do it instead.

It seems that we can reproduce the same issue on the mac as well. I suppose I could change the juce timer thread to process timers in its run function rather than routing through the message queue system, though that would introduce a need for message manager locks which we have avoided so far.

Unless we are working in a completely different way to everyone else, this is likely to come up again as more people move to support the AAX format and it’s AudioSuite equivalent. In that instance, is this the change that you would make or can you think of a better solution?

Thanks for your time

Just remembered: there’s a Timer::callPendingTimersSynchronously() method that the VST classes call from their idle() callback to avoid getting blocked by the host - is there an idle call in RTAS that could do the same thing?

After all this I can neither find an idle function nor any other way of determining whether the plug-in running is using AAX RTAS or AS… back to the drawing board I think :?