Mark Knecht wrote: > On Wed, May 28, 2008 at 9:31 AM, Pieter Palmers <pieterp@xxxxxxx> wrote: >> Mark Knecht wrote: > <SNIP> >>> P.S. - I didn't understand your comment earlier about a globally >>> available 1394b clock. I worked on that spec and I just don't remember >>> that. Been too long I suppose... >> I'm talking about the Cycle Timer Register that is globally available to all >> nodes. It's incremented by the cycle master at 24.576MHz, and all nodes have >> (approximately) the same view of this clock. All audio samples transported >> on the 1394 bus are timestamped relative to this cycle timer. This means >> that every sample has an "absolute" time attached, no matter what device it >> is sent to. This enables the use of multiple devices, like you suggest, >> without any form of external sync. It even beats wordclock sync since that >> only ensures relative sync (same rate), but still leaves an ambiguity in the >> exact absolute time a sample should have. >> >> I hope that refreshes things a bit :). >> >> Greets, >> >> Pieter >> > Ah, the refresh that helps my pausing brain. Thanks Pieter! > > Now, as a hardware design engineer, it's clear that the host receiving > all this data from the bus can have an accurate picture of which each > sample was sent over the bus. However if each source (in my example of > 3 8-I/O units) is using it's own sample clock there is still the > inaccuracy of each unit's 44.1KHz clock being slightly different. (One > at 44,099, one at 44,100, and the 3rd at 44,101) It's that difference > that causes me to always attempt to use a single hardware clock > source. > > Do you know whether Presonus devices do anything to address this specifically? > > I currently use sync-to-ADAT, sync-to-spdif and Word Clock here. I've > not done any syncing over my Fireware interfaces. > You have the exact timestamp of each sample, and you have the clock this timestamp is referred to. Hence you can use these timestamps to drive a PLL and generate the clock signal. Knowing the absolute time of a sample implies rate sync (i.e. clock sync). Rate sync on it's own however does not give any information on absolute timing. The simple way to think about it is to obtain the clock for the audio streams from the pulses generated as follows: 1) take the next sample 2) take the timestamp from the sample 3) wait for increase of CTR register (global firewire clock) 3.1) if timestamp = CTR generate pulse and goto 1 3.1) if timestamp != CTR goto 3 This generates a pulse stream at exactly the rate of the audio data. Use this to drive a PLL and you have rate sync. There is only one clock source in the system, i.e. the actor that generates the timestamps on the data. Greets, Pieter _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
