On February 20, 2010 01:19:52 pm Paul Davis wrote: > On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf > > <[email protected]> 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. Tim. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
