AAX Wrapper doesn't fetch plugin latency

#1

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.

#2

Hmm, reading the docs a bit more, it looks like I was incorrectly using the GetSignalLatency function.

Try adding this, at line 685?

[quote] AudioProcessor& audioProcessor = getPluginInstance();

        check (Controller()->SetSignalLatency (audioProcessor.getLatencySamples());
        
        audioProcessor.setPlayConfigDetails (numberOfInputChannels, numberOfOutputChannels, sampleRate, bufferSize);
        audioProcessor.prepareToPlay (sampleRate, bufferSize);

[/quote]

And I’m assuming that the existing code that does this…

int32_t bufferSize = 0; check (Controller()->GetSignalLatency (&bufferSize));

…must actually just always be returning 0, so it can probably just be got rid of, and this call changed to simply use 0:

audioProcessor.setPlayConfigDetails (numberOfInputChannels, numberOfOutputChannels, sampleRate, 0);

0 is a bit awkward there, because it’d be nice to tell the plugin the expected block size, but I can’t see any way of getting it.

#3

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.

#4

Hmm. I get a very odd message when I try to compile. Code in there is a little thorny, so I’ll just see if this rings any bells for you:

[quote]/blah/blah/juce/modules/juce_audio_plugin_client/AAX/juce_AAX_Wrapper.cpp:686:
Passing ‘const AAX_IController’ as ‘this’ argument of ‘virtual AAX_Result AAX_IController::SetSignalLatency(int32_t)’ discards qualifiers[/quote]

#5

you’re just calling a non const function with a const object.

Check if the requirement for AAX_IController being const should be enforced previously

#6

Ah, you might need to remove the constness, e.g.

check (const_cast<JuceAAX_Processor*>(this)->Controller()->SetSignalLatency (audioProcessor.getLatencySamples());

#7

[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!

#8

Ok, thanks - I’ve checked that in now, it seems to make sense.

#9

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].

#10

Yes… Good idea, I’ll change that.

#11

Thanks for moving quickly on this Jules. You’ll make a lot of end-users much happier.

#12

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

#13

Sorry, will tidy that up in a moment…