On Tue, May 8, 2012 at 10:30 AM, Ralf Mardorf
> Using MTC with different Linux software and different external hardware
first of all, MTC is not a particularly reliable protocol unless you
can dedicate the equivalent of a MIDI cable to it. its data rate gets
close to the serial MIDI limit, so if you start dumping substantial
amounts of additional data on the same physical serial cable, MTC
accuracy will suffer.
secondly, to transmit MTC in the way that some pre-generic-OS systems
do really requires a thread dedicated to nothing but MTC. very few
sequencers on any platform implement their MTC support in this way.
they should not have to if the MTC receiver has a well designed
PLL/DLL to remain synced. the problem is that many receivers (even if
they do not transmit MTC in the "canonical way" - i.e. actually
emitting a quarter frame message at a fixed interval) expect to
receive it in canonical form and do not use a PLL/DLL to sync, or they
use a very poor equivalent. the result is that if the MTC transmitter
is doing block structured audio, and actually delivers MTC in a
somewhat bursty fashion, the receiver(s) fail to sync correctly.
in the early 2000's there were a number of MIDI h/w interfaces on the
market specifically designed to help address this sort of issue. they
didn't do well in the marketplace. the correct way to handle this is
to correctly write receivers to be able to sync to both canonical and
"bursty" MTC streams, which is not hard and should really have been in
place to begin with.
> It would be nice if we could sync apps and anyway could use loop play.
MTC is inherently unsuited for loop playback since it requires a
locate to an arbitrary location. Looping playback really needs a
predetermined loop to work nicely. MTC cannot do this. MMC can, but is
rarely used for this.
Linux-audio-dev mailing list