[LAD] SMPTE and jackd

[Paul Davis]

On Fri, May 11, 2012 at 10:01 AM, gene heskett <gheskett at wdtv.com> wrote:
> On Friday, May 11, 2012 09:17:37 AM Jens M Andreasen did opine:
>
>> On Fri, 2012-05-11 at 07:34 +0200, Ralf Mardorf wrote:
>> > That's why
>> > Paul explained it (to us/me) and he's right.
>>
>> No, that's crap ... "Many" (which one?) is not equal to ALL. Just
>> because some idiot hired gun working for a no-name-brand couldn't be
>> bothered, does not mean the whole world is condemned to doing things the
>> wrong way. Trash that machine or use it as a doorstop ...
>>
>> ;-)
>
> I think I'll have to agree with Jens here.  If the hardware can't do it,
> put it someplace it can do something useful, door stop or window prop as
> needed.

   [ ... elided ...]

none of that has really anything to do with the reason why some things
don't handle MTC or other sychronization signals well.

MTC and timecode are specified as a signal that should in theory be
delivered as a continuous stream of messages with a fixed interval.
However, it isn't necessary for them to be delivered in this way in
order for the receiver to still sync extremely accurately to them.

all general purpose CPUs process audio in chunks (the chunks might be
big or small but they are still chunks) whose size is totally
unrelated to the nominal interval between the messages that form an
MTC or other timecode stream. if software running on such a cpu
delivers the timecode stream in a way that is driven directly by the
flow of audio through it, then its entirely possible for it do quite
"bursty" transmission of the timecode stream. in one processing chunk
it might emit two timecode messages, in another it might emit none.

receivers that are engineered with the presumption that the signal
will flow with a fixed interval will fail to sync to this signal (or
won't sync very well, depending on precisely how they are
constructed). in contrast, receivers that don't make this presumption
and instead use reasonable engineering practice - a PLL/DLL to sync
between two clocks - will be able to sync to it in the face of almost
any level of burstiness in the signal.

now, in addition, it would certainly be good if the software running
on general purpose CPUs that sends timecode would actually use a
separate thread and attempt to ensure fixed interval messages. this
is, however, significantly more complex than the use of a PLL/DLL in
the receiver, and so its not surprising to find the state of the world
as it is.