From: Jonathan W. <jw...@ph...> - 2010-12-08 22:47:25
|
Pieter Palmers wrote: > > This is how the Fireworks driver currently works. (Because SYTs wrap > > around after 2 ms, and the length of the Tx packet queue is an integer > > multiple of that, the offset value happens to be zero. :) > > SYT's wrap after 16 packets, meaning 49152 firewire ticks, which is 2ms > when using the oscillator driving the 1394 bus as a reference. The "generic" driver cannot rely on this "standard" SYT behaviour because the SYT field is not used in the standards-compliant way in the RME and MOTU protocols (in both cases it's either 0x0000 or 0xffff, depending on certain mechanisms which are still not entirely understood). Of course assuming the driver separates the low-level packet formatting functionality this won't be an issue - the RME/MOTU functions can just ignore SYT - but only if other parts of the streaming driver don't assume that SYT is useful. > Suppose also that the firewire clock is generated by the audio device. > In that case there are 8000 cycles/wc_sec * 3072 ticks/cycle = 24576000 > ticks/wc_sec. Therefore the number of ticks/frame is exactly 512, hence > FS=512. I should also note here that even this special case is very special. MOTUs tend to win the iso manager election in most cases and thus the firewire clock is generated by them, and yet they still don't lock the iso cycle counter to the audio clock. So the scenario you outlined where the firewire clock is not generated by the audio interface is in fact more common than it would first appear. As for the rest of the logic you outlined I'll read it in detail tonight and comment if anything occurs to me - I don't have the time right now. Regards jonathan |