Well people...This is from the actual IEEE1394 Institute's own white paper on the standard:
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.
|
So I read on...to the info on sample rate smoothing...& the white paper (the IEEE1394 Institute's
own white paper) states that (& I'm paraphrasing here, because for some reason the .pdf doesn't permit copying):
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.
|
Not so sure I want to go this route, now.
mark4manBTW - Granted...this info
does fall under the IEC61836-6 protocol, which
is the audio data
transmission protocol...so maybe Gunnar has a point, I don't know. But then again, if this is used to feed the DAC (which the paper suggests), then...as JD says...jitter only affects sampling, so the output of the AI
would be affected (which would have an impact on monitoring, correct?)