[LAD] midi beat clock

Tim E. Real termtech at rogers.com
Sat Feb 20 21:22:50 UTC 2010


On February 20, 2010 02:38:19 pm Tim E. Real wrote:
> On February 20, 2010 01:19:52 pm Paul Davis wrote:
> > On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
> >
> > <ralf.mardorf at alice-dsl.net> wrote:
> > > If Linux apps would use JACK transport the coders only would have to
> > > take care to handle this. Just having on app doing sync among JACK and
> > > eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
> > > of such an app too ... I didn't read the whole thread, perhaps this was
> > > mentioned before.
> >
> > this isn't true.
> >
> > one of the most deliberate and conspicuous design decisions of the
> > JACK transport API is that there is no support for varispeed.
> >
> > sync requires knowing two things: where we are, and how fast we are
> > going. JACK transport has only 2 answers the the second question
> > (stopped, rolling). this isn't adequate to fully capture the notion of
> > sync.
>
> MTC: Maybe veering OT a bit but if we could just touch on this for a
> moment. Was going to ask about this anyway, as we had talked about it a
> bit.
>
> I thought "it's too bad we can't adjust Jack's sample rate on the fly"
>  thus allowing Jack to behave like a Voltage Controlled Oscillator in a
> PLL, syncing to MTC frame.
> I was thinking the VCO 'control' signal would come from a client.
> Else Jack itself would have to support MTC.
>
> But raises the question - which Jack back-ends allow dynamic sample rate
>  changes? And with a finite resolution small enough?
>
> I concluded that the best way for me to sync Jack audio with an
>  external MTC is with app-side audio time stretchers.
I forgot to add that if one is faced with external MTC (or any frame-based
 sync signal) then it should really be fed (somehow) into the sound card 
 as a sync signal, shouldn't it? Everything supports SPDIF, but MTC?
Then sound card + Jack + apps are happy, as they all run off it.

And using MTC to send sync between apps just seems odd, as they're
 using Jack already, for audio. 

 



More information about the Linux-audio-dev mailing list