On Fri, May 11, 2012 at 10:01 AM, gene heskett <ghesk...@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. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev