29 May
2008
29 May
'08
9:32 a.m.
Mark Knecht wrote:
On Wed, May 28, 2008 at 9:31 AM, Pieter Palmers
<pieterp(a)joow.be> wrote:
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
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