AAX+OSX - ppq Position not updated regularly at fs>48kHz [solved]


Hi Everyone,

I am working on an AAX plugin on OSX with PT12. I discovered yesterday that the audio callback seems to be called twice during Playback (not Recording!!) for the same block of data for samplerates > 48kHz. This obviously completely messes up any states in the my processor.

I am completely tapping in the dark to find the reason for this issue and are thus reaching out to you for any clues.

To reproduce the issue, save the position of the playhead at the beginning of each block and compare it to the last position like so:

void AudioClockAudioProcessor::processBlock (AudioSampleBuffer& buffer, MidiBuffer& midiMessages)
    (clear output buffers)
    AudioPlayHead::CurrentPositionInfo CurrentPosition;
    getPlayHead()->getCurrentPosition (CurrentPosition);
    double currentPpqPosition = CurrentPosition.ppqPosition;

    if(currentPpqPosition == lastPpqPosition){
        ppqStrLogger[ppqStrLoggerIdx] += "Duplicate at block ";
        ppqStrLogger[ppqStrLoggerIdx] += blockIdx;
        ppqStrLogger[ppqStrLoggerIdx] += ":";
        ppqStrLogger[ppqStrLoggerIdx++] += String(currentPpqPosition);

    lastPpqPosition = currentPpqPosition;

At 88.4/96 kHz, I get the same position twice for each block reliably

My setup:

OSX 10.11.4
JUCE 4.3.0 - release
PT 12.4.0 DEV
using the onboard MacBook soundcard

Has anyone seen this kind of behavior before?



The ppq (=pulse per quarter) also known as ticks is a rough measure. Many samples fit into one tick. And Pro-Tools can run on very small buffer sizes. So to see, if processblock is called multiple times (btw. I doubt it, any programm would get in trouble like you said), better check with AudioPlayHead::CurrentPositionInfo::timeInSamples.

Good luck


Hi Daniel,

thanks, that was a good pointer! Although the ppq position is said to have a resolution of 1/960ppq on the web, it appears to be only updated every second block! Here’s the output of

blockIndex : ppqInfo : timeInSamples

timeInSamples changes as expected and I think I can take it from there.

All the best,



The first rule of writing audio plugins is never to assume that the host will do what you expect it to! All hosts will be quirky/buggy, especially when it comes to time-related stuff like this.


Yes. It’s too bad as I was also not able to simply derive the ppq Position from timeInSamples, BPM and fs - this runs away from the hosts playhead due to round-off errors in some DAWs.

Looks like it needs some informed hacking to combine both chunks of data to make it work reliably.

If anyone has done something similar and is able to share some best practices, this would of course be very much appreciated.


I have had too much trouble with ProTools sending inaccurate playhead messages so I use Midi Time Code for all of my syncing in Juce and it works really well. See the class MidiMessages and the wikipedia article for Midi Time Code. Juce provides functions for parsing timing messages - getting subframe accurate info is possible with this.