20 Feb
2010
20 Feb
'10
3:48 p.m.
On February 20, 2010 01:19:52 pm Paul Davis wrote:
On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
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.
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.