I’ve just been scouting a problem in which AAX plugins don’t return the plugin latency to ProTools. I’ve found that all of the other wrappers call the [color=#0000FF]AudioProcessor::GetLatencySamples[/color] method. But that call isn’t made in the AAX wrapper. The closest thing I can find in [color=#0000FF]juce_AAX_Wrapper.cpp[/color] is a call to [color=#0000FF]GetSignalLatency[/color]. That might serve the same purpose, but it doesn’t appear to end up calling [color=#0000FF]GetLatencySamples[/color]. At this point the trail runs cold. Anybody know anything about this?
Don’t know if it matters in this case, but I’m using the 1.5 AAX SDK. Haven’t moved to the 2.0 Beta yet.
I’ll give that a try and let you know what happens. FWIW, the expected block size in PrepareToPlay is not a value I use anyway, since it’s not alway a reflection of reality (this is especially true with the Apple AUval tool, which constantly throws variable (and quite odd) block sizes at anything it’s testing. I use the sample count that comes with each block to process and then unpack into my own vectors as appropriate.
That’s all a long-winded way of saying that I don’t care if the expected block size is accurate or not.
[quote=“jules”]Ah, you might need to remove the constness, e.g.
check (const_cast<JuceAAX_Processor*>(this)->Controller()->SetSignalLatency (audioProcessor.getLatencySamples());
[/quote]
One more close-paren at the end of that line and the build works fine. I’ve just tested this on a (cough) pre-release version of PT and it reports what it should. I’ve got to crank up another machine to see how it works with 32-bit release code at varying sample rates. But this first test is encouraging. Thanks!
There might be a gotcha in there. The [color=#0000FF]prepareToPlay[/color] routine is the first point that the plugin knows the actual sample rate, ands that’s when it might adjust its latency. But the AAX [color=#0000FF]SetSignalLatency[/color] routine is called before [color=#0000FF]prepareToPlay[/color] so it may not get an accurate value from [color=#0000FF]audioProcessor.getLatencySamples[/color]. It might be better to call [color=#0000FF]SetSignalLatency[/color] after [color=#0000FF]prepareToPlay[/color].
Oops. I’m afraid one more little tweak is needed in the AAX wrapper. You were fetching [color=#0000FF]bufferSize[/color] before calling [color=#0000FF]prepareToPlay[/color]. You determined that you were always getting 0, so it appears you removed the call to fetch [color=#0000FF]bufferSize[/color]. That variable no longer exists. But you’re still passing it as an argument to [color=#0000FF]prepareToPlay[/color], causing a compiler failure. If you just stick a zero in there, you’re probably fine