On Thu, May 29, 2008 at 4:32 AM, Pieter Palmers <pieterp@xxxxxxx> wrote: > 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 > Right, but I don't think that's enough. Let me exaggerate a bit and excuse me being so simplistic. It's for example only and has nothing to do with my respect for you and you're work. This is as much for other readers. Let's assume we have two different Presonus devices. One of the devices has a clock that's a little fast - let's say 50KHz instead of 44.1KHz while the second device has a clock that's a little slow, let's say 40KHz. Both of these audio sample clocks are free running and have nothing to do with each other. So what happens? After 5 seconds have passed the first device has generated 250K sample while the second device has generated only 200K samples. If I put these two sample streams side by side in Ardour the second stream will need to use an extra 25% of it's samples to fill the same time period. when the two streams are then played the pitch of the second stream will be raised. (and/or the pitch of the first stream will be lowered.) I will grant you that if someone wanted to resample both streams in real time using the time stamps provided in the 1394 stream then both could be brought closer together. Does the FreeBob stack do that? Now, obviously the 50K/40K difference isn't reality. More realistic is +/-100 (expensive) or +/-200 PPM (fairly inexpensive) on the audio crystal. Assuming that I ran the calculator correctly (it's 6:30AM here) then 1 hour of recording at 44.1K generates 158,760,000 samples. At 200PPM my fast interface will generate 31752 samples more than the base rate while my slow device will generate 31752 fewer samples. Therefore after 1 hour the two streams are separated by 63504 samples. In time this is about 1.44 seconds which is certainly audible. Even on a 5 minute pop song the difference is about 120 mS which is well into the echo range. (Drums and guitar are in sync when the song begins but the drums are late at the end.) To the best of my knowledge the only way around this is synchronizing the audio sample clocks. I do this with an external signal to all of my audio sampling devices. It is possible, and why I asked earlier, that devices could create their audio sample clock from the time stamp being sent by the 1394 bus master but there is, to the best of my knowledge again, no requirement that they do so an I doubt many do. thanks, Mark _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
