MTC Chase or Locking



I'm interested in developing some features where I can have a JUCE based application chase MTC. That is read incoming MTC and start the JUCE audio sub-system in sync with the MTC.


From looking at the JUCE audio APIs it's unclear to me clocking and synchronized playback would work (if this is implemented currently).


Is it possible to install a clock that the JUCE audio sub-system will lock against?

Is it possible to trigger audio play start on a specific clock value?




You would need to implement some clock locking scheme yourself, probably using a delay locked loop (, to get a clock that is synced with the MTC. And then use a high resolution clock on the JUCE audio side, and then work out a relationship between the two to be able to sync audio (via some form of async sample rate conversion). Non-trivial issues for sure.


I was thinking about it from the point of view of having both systems (JUCE audio and the MTC generating device) are locked to the same underlying clock (WordClock, AES, etc.) and not actually trying to solve slaving JUCE audio against the MTC signal but rather locking to the position of the MTC. 

If the MTC source and JUCE drift apart, you could detect the drift, drop playback, and resync playback. Alternatively, you could jam-sync (lock and drop i.e. lock playback and no longer monitor synchronization).

Assuming that the MTC source and the I/O the audio subsystem is using the underlying clock...

My question is related to what existing functionality there is for asking what the current running sample time of the audio sub-system and starting playback on a specific sample in the future (a play trigger sample).

I would guess that the JUCE audio subsystem is not implemented this way.

Does anyone have clarity on this specific functionality/support?