Quote: |
Since FireWire is a packet switched bus, there's no synchronous clock carried along to convey timing. And, there are myriad sources of jitter within the 1394 transport protocol, the main source being that you have a free running oscillator in every node on the bus. Says Julian Dunn,“The IEEE 1394 format uses asynchronous clocks at each node. The interaction of these clocks with each other and with the sample (word) clock generates jitter.” |
Quote: |
IF you get large enough "jitter" on the firewire bus, you will loose full ASIO buffers, and that is sort of not going without being noticed. |
mark4man wrote on Fri, 10 February 2006 16:12 | ||
All these damn Firewire interfaces, man !!! This from the Seneschal site:
I'm about to upgrade my studio's converters & was bustin' my butt to stay w/ PCI (or go to AES/EBU w/ an AES > PCI interface)...'cause If no less than Julian Dunn is worried about jitter, then I am to. |
bobkatz wrote on Fri, 10 February 2006 15:57 |
I'm not sure if you're taking Julian out of context or what, because he certainly understands, as does Dan Lavry, how to deal with collecting "jittery" data and making it clean again. |
Quote: |
With a properly-designed Firewire interface, jitter is the least of your worries. |
dcollins wrote on Sat, 11 February 2006 01:17 |
The guys on the DICE chip seemed to give it a pretty high priority. DC |
Quote: |
Synchronization & Time-Stamping: In the simplest scenario, the receiver buffers the audio data until CYCLE_TIME=SYS. In practice, due to the need to keep jitter to a minimum for high-quality audio, more sophisticated smoothing is required. The CYCLE_TIME clock is subject to jitter that, though possibly acceptable for normal applications, is too great for high-end audio applications. |
Quote: |
The CYCLE_TIME and SYS timestamps, although adequate for normal audio, are not the ideal solution for clock recovery, due to the following: The clock is not a linear timebase. The IEEE1394 clocks themselves suffer from jitter. The cycle time is 128 us or 8 kHz But...the Oxford Semiconductor OXUF922 reference design handles the problem by using an embedded ARM processor to correct the timing of incoming isynchronous packets & presents audio data to the DACs with a corrected timebase. The high-end solution to this problem involves controlling a high-stability external PLL, or an array of PLLs. ...& the OXUF922 design COULD BE MODIFIED to drive such an external circuit for audiophile applications. |
bobkatz wrote on Fri, 10 February 2006 16:57 |
B.J. Buchalter, designer of the Metric Halo Mobile IO, could tell us all a lot more about these considerations, but one thing is for sure, he's conquered any jitter issues there might be with Firewire. You just don't want to try to "clock" off the data. That would be stupid anyway. |