AudioPlayHead issue with Audio Units

Hello,

I have discovered this issue on my app but I was able to reproduce it in the juce audio plugins host.
I have created a dummy class that implements juce::AudioPlayHead and I have set it to the graph in the PluginGraph Constructor.

class MyAudioPlayHead : public AudioPlayHead
{
public:
static MyAudioPlayHead& get()
{
static MyAudioPlayHead instance;
return instance;
}
virtual bool getCurrentPosition (CurrentPositionInfo& result) override
{
memset(&result, 0, sizeof(CurrentPositionInfo));
result.timeSigDenominator = 4;
result.timeSigDenominator = 4;
result.bpm = 120;
return true;
}
};

//==============================================================================
PluginGraph::PluginGraph (AudioPluginFormatManager& fm, KnownPluginList& kpl)
: FileBasedDocument (getFilenameSuffix(),
getFilenameWildcard(),
“Load a graph”,
“Save a graph”),
formatManager (fm),
knownPlugins (kpl)
{
newDocument();
graph.setPlayHead(&MyAudioPlayHead::get());
graph.addListener (this);
}

Nothing fancy and as expected the getCurrentPosition is constantly called when I add a plug-in that obviously queries it. But if I go to audio settings and change the sample rate or the buffer size which I assume will reset the plug-in by calling releaseResources and prepareToPlay the getCurrentPosition is not called anymore (In my app, I tried calling the setAudioPlayHead everytime just before the prepareToPlay but same problem)

This is happening in MAC and for audio units only. I have tried VST3 (again in MAC) and they seem to work as expected. I have tried two different audio unit plug-ins (one being Kontakt and the other one a simple guitar instrument) and they both had the same problem.

The further I got was the method

static OSStatus getBeatAndTempoCallback ( void * hostRef, Float64* outCurrentBeat, Float64* outCurrentTempo)

{
return static_cast <AudioUnitPluginInstance*> (hostRef)->getBeatAndTempo (outCurrentBeat, outCurrentTempo);
}
which is obvisouly not called after sample rate/buffer size change

Looking forward to understand this…

I haven’t looked at the exact definition of the CurrentPositionInfo definition, but I think the memset call is not a good idea.
The struct should be initialised correctly by default by the caller and you only set the information you have.

About the actual problem, you might haver to re-add the AudioIODeviceCallback. The AudioDeviceManager is a ChangeBroadcaster, maybe you can catch that callback and fix it there (which makes sense, the device could also have changed)

N.B. please add three back-ticks around your code for code formatting

I will keep the focus of this conversation to the actual problem:

As I explained, this looked like a bug in audio units as VST3 work fine. Your suggestion was not clear to me at all so I was forced to investigate myself further. To my understanding, releaseResources is removing some callbacks (not the AudioIODeviceCallback). The solution which fixes my problem was to

call createPluginCallbacks();
at the very early of the method prepareToPlay() in the juce_AudioUnitPluginFormat.

I am not convinced that this is the best solution but it will do for me (and maybe others). I do hope that you will provide a better fix as you know the code there a lot better.

Thanks for your time

createPluginCallbacks() was changed to setPluginCallbacks() a few minor versions ago.

I can’t reproduce the issue on the current develop branch, so this could be something that was fixed recently.

Can you check if there is still an issue on develop?

I used the following patch that changes AudioPluginHost and AudioPluginExample so that AudioPluginExample is displaying the playhead position. It’s pretty much in line with what you suggested, but there could be a subtle difference.

playhead-test.patch (8.5 KB)

Hello,

Thanks for looking further into the issue.

I just looked at the juce_AudioUnitPluginFormat.mm in your current repository and I can see that there is a fix similar to mine. setPluginCallbacks() is called at the very early of prepareToPlay.

image

I guess that is why you cannot reproduce it and I am pretty sure as you have suggested that this is indeed fixed in the develop branch.

You may safely consider this issue solved. Thanks again for your time