28 May
2008
28 May
'08
5:31 p.m.
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.
Cheers,
Mark
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