Re: [FFADO-devel] DICE and ffado

[Pieter P. <pi...@jo...>]

On 12/14/2010 08:37 AM, Daniel Wagner wrote:
> Hi Pieter,
>
> On Mon, Dec 13, 2010 at 07:03:59PM +0100, 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 pseudo-code 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
>
> I might have missed it, but where do you address the problem, that the
> external word clock and firewire clock are not in sync?

Through the wc_sec/fw_sec ratio, which represents the ratio between one 
'word clock second' and one 'firewire second'.

wc_sec/fw_sec == 1 => the WC and FW clocks are in sync
wc_sec/fw_sec > 1  => the WC clock runs faster than the FW clock
wc_sec/fw_sec < 1  => the WC clock runs slower than the FW clock

If the clock frequency itself doesn't drift for both clocks, this ratio 
will be constant.


Suppose both devices generate the clock using a cristal with nominal 
frequency 24576000MHz. Suppose also that we have a common reference 
clock (e.g. an atomic clock) that ticks in "real_seconds".

In reality the two crystals are not atomic clocks so they will not tick 
exactly at 24576000 ticks / real_second. Furthermore they are not in 
sync, so they tick at a different rate.

Assume e.g.:
FOSC_FAD = 24576010MHz = 24576010 FAD_ticks / real_second
FOSC_PC  = 24575990MHz = 24575990 PC_ticks / real_second

If either of these clocks generates the firewire clock, the concept of 
'second' in that clock domain is defined as 24576000 ticks of the 
respective clock. therefore:

1 FAD_sec = 24576000 FAD_ticks
1 FAD_tick = 1/24576010 real_sec
=> 1 FAD_sec = 24576000/24576010 real_sec (A)

1 PC_sec = 24576000 PC_ticks
1 PC_tick = 1/24575990 real_sec
=> 1 PC_sec = 24576000/24575990 real_sec (B)

hence dividing A by B:
FAD_sec/PC_sec = 24575990/24576010 = FOSC_PC/FOSC_FAD

i.o.w. this ratio is equal to the drift between the two clocks.

The nice thing about using ratio's of what a second means is that you 
eliminate the tick rate from the calculation, which comes in handy if 
the tick rates are not equal. In casu for the wordclock vs firewire 
clock we can use the wc_sec/fw_sec ratio, as both clock domains define a 
'second': wc_sec = 48000 wc_ticks, fw_sec = 24576000 fw_ticks.

I hope this clarifies my reasoning a bit,

Pieter