From: Pieter Palmers <pieterp@jo...>  20101214 07:34:13

On 12/13/2010 07:03 PM, Pieter Palmers wrote: > On 12/13/2010 11:44 AM, Clemens Ladisch wrote: >> Pieter Palmers wrote: >>> I've more formally summarized the AMDTP timestamp calculation strategies >>> as I see them in: >>> http://www.ffado.org/download/amdtp_timestamp_notes.pdf >>> >>> In it I conclude that the pseudocode is only valid if queue_length % 16 >>> == 0. >> >>> "TPF represents the number of ticks per audio frame, and is not >>> independent from the bus configuration." >> >> But the ticks are based on the bus clock, which runs at a constant >> speed, and the audio frames are based on some internal or external >> clock, which also runs at a constant speed. So how does this depend >> on the bus configuration? > > Suppose that the audio clock is generated externally by e.g. a dedicated > wordclock generator that is set to 48000 frames/sec. Let's define time > in function of this external clock, i.o.w. there are exactly 48000 > frames in one 'wordclock second' (wc_sec). > > This audio clock is then connected to the firewire audio device that > syncs on this external clock. It will therefore sample exactly 48000 > frames/wc_sec. => frames/wc_sec = 48000 > > The firewire audio device (FAD) is connected to the PC through the > firewire bus. One way or the other a bus master election mechanism chose > a cycle master. This will generate the 1394 clock to be 24576000 ticks > per 'firewire second'. => ticks / fw_sec = 24576000. > > Therefore the number of ticks per frame is: > TPF = 2457600 ticks/fw_sec / (48000 frames/wc_sec) > = 512 ticks/frame * wc_sec/fw_sec > > Which is busdependent due to the the wc_sec/fw_sec factor. As long as > the bus topology is fixed, wc_sec/fw_sec is constant. However if the bus > topology is changed and a new cycle master is elected, this ratio will > be different. > > In the end, all that counts is the delay in 'wordclock seconds', as that > drives the data converters, and hence will determine the phase of the > audio signals. > > To figure out how a certain delay D in ticks affects the phase of the > audio signal we can skip the frames all together: > > DELAY_IN_WC_SECS = DELAY_IN_TICKS / (ticks/fw_sec) * (wc_sec/fw_sec) > > Suppose DELAY_IN_TICKS is constant. ticks/fw_sec is fixed by the 1394 > spec to 24576000. Therefore as wc_sec/fw_sec is bus topology dependent, > DELAY_IN_WC_SECS will be bus topology dependent. > > So if the driver would add a fixed DELAY_IN_TICKS to a SYT timestamp, > the following scenario can occur: > 1) We start the driver with the FAD and the PC on the bus. the FAD is > elected as cycle master. This results in a delay D1 in realworld seconds: > D1 = DELAY_IN_TICKS * 24576000 * (wc_sec/fw_sec_by_FAD) > > FAD == 1394 cycle master > => fw_sec_by_FAD = wc_sec > => D1 = DELAY_IN_TICKS * 24576000 * 1 > > 2) We hotplug a firewire harddisk, causing a bus reset, potentially > resulting in a new cycle master(*). Suppose now the PC is the cycle > master. The realworld delay D2 now becomes: > D2 = DELAY_IN_TICKS * 24576000 * (wc_sec/fw_sec_by_PC) > > FAD != 1394 cycle master > => fw_sec_by_PC != wc_sec > => D1 != D2 > > Hence a bus modification resulted in a realworld timeshift of the streams. > There is a small error in the above, the actual equations are: D1 = DELAY_IN_TICKS / 24576000 * (wc_sec/fw_sec_by_FAD) and D2 = DELAY_IN_TICKS / 24576000 * (wc_sec/fw_sec_by_PC) but that doesn't change the actual conclusion that D1 != D2. Last night however I was thinking about whether this is in fact relevant given the fact that there are specs on the clocks. It might as well be that the constraints put on the cycle clock by the 1394 spec makes that we don't have to care. From IEEE Std 13941995: " The cycle master tries to transmit a special timing request called a “cycle start” at specific intervals set by a “cycle synch” source (nominally 8 kHz ± 100 ppm, or 125 µs ± 12.5 ns). " => 12.5ns * 24576000 ticks/sec = 0.3072 ticks => '1 cycle ± 0.3072 ticks' In other words: the maximum difference between the length of a cycle as defined by two different cycle timer clocks is 0.6144 ticks. Therefore, at worst: 8000.6144 ticks / fw_sec_by_PC = 8000 ticks / fw_sec_by_FAD => fw_sec_by_FAD/fw_sec_by_PC = 8000/8000.6144 How does this impact us? dD = D1D2 = DELAY_IN_TICKS * 24576000 * (wc_sec/fw_sec_by_FAD)  DELAY_IN_TICKS * 24576000 * (wc_sec/fw_sec_by_PC) assuming that wc_sec == fw_sec_by_FAD: dD = DELAY_IN_TICKS * 24576000 * wc_sec * (1  fw_sec_by_FAD/fw_sec_by_PC) Therefore the worstcast delay is: dD = DELAY_IN_TICKS / 24576000 * wc_sec * ( 18000/8000.6144 ) = DELAY_IN_TICKS * 3.12476e12 * wc_sec As the SYT is modulo 16cycles, the maximum offset we can add is 16*8000 ticks, so: dD = 16*8000 * 3.12476e12 * wc_sec = 4e7 wc_sec which is 1 cycle of a 2.5MHz clock, or 7.7% of the duration of a 192kHz frame. This leads me to conclude that although the phase shift in the signals is dependent on the bus topology, it is a bit of a theoretical issue and not relevant for audio applications. For audio applications we can assume that a seconds are created equal on the firewire bus (fw_sec_by_* == fw_sec_by_*). Please correct me if I'm wrong, it wouldn't be the first time. Regards, Pieter 