R/E/P Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: [1]   Go Down

Author Topic: Firewire Jitter Worries ???  (Read 3672 times)

mark4man

  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
Firewire Jitter Worries ???
« on: February 10, 2006, 04:12:26 PM »

All these damn Firewire interfaces, man !!!

This from the Seneschal site:

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.”

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.

But...say the A/D conversion is taking place inside an outboard AI or breakout box...& that breakout box is in turn feeding the firewire buss the converted digital signal (thru the DAW software & onto the hard drive)...I guess I'm saying I don't understand what the worry is...'cause the main concern with jitter is "conversion" jitter, right?  If the audio is converted to digital outside (& prior to) the box, then esentially you're using the firewire bus to transfer the data to the HD inside the workstation.

Is that also a concern?

mark4man
Logged

Gunnar Hellquist

  • Full Member
  • ***
  • Offline Offline
  • Posts: 206
Re: Firewire Jitter Worries ???
« Reply #1 on: February 10, 2006, 05:45:37 PM »

Don't worry, be happy. The firewire bus is only used to transfer already converted data. Jitter is totally unrelevant for data going on the bus.

If you have only one AD set that as master, the converter will be driven by the crystal inside that box, and with really very little jitter. If you have several AD-s, I would set the most important AD as master and slave the others on word-clock cable (the 75 Ohm coaxial cable, with proper termination of course). If you like the convenience you might want to have an external clock generator, but that first AD will probably not sound better.

IF you get large enough "jitter" on the firewire bus, you will loose full ASIO buffers, and that is sort of not going without beeing noticed.

Logged
Gunnar Hellquist
unafiliated

mark4man

  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
Re: Firewire Jitter Worries ???
« Reply #2 on: February 10, 2006, 06:44:27 PM »

Gunnar...

Thanks, man.

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.

But see...this is my concern (&...it's always the unknown that drives men's fears, right?)  If you could explain "jitter on the firewire bus" a bit further it would sure be appreciated.  The Dunn white paper must have been referring to something.

The thing that's hard for me to come to grips with is the lack of sync (the asynchronous packet-based transfer.)  S/P DIF has the embedded clock.  Same deal w/ ADAT.

Now...during the tracking stage of my upcoming CD, I used to grab tracks at our sister studio right off their workstation's HD via USB 2.0 to an external hard drive; & in turn transfer same into the workstation at my end...& never think twice about it because it was a transfer of pre-recorded data.

But for real-time tracking, even tho it works as you explained earlier, shouldn't there still be some sort of sync...or...where (& how) does this "jitter on the firewire" bus occur?

Thanks again,

mark4man
Logged

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Firewire Jitter Worries ???
« Reply #3 on: February 10, 2006, 06:57:44 PM »

mark4man wrote on Fri, 10 February 2006 16:12

All these damn Firewire interfaces, man !!!

This from the Seneschal site:

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.?

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.




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.

With a properly-designed Firewire interface, jitter is the least of your worries. A good firewire interface uses a local, isolated clock oscillator to control the converters. Since the computer has total control over the data coming in and out, buffer control is not a big deal.

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.

BK
Logged
There are two kinds of fools,
One says-this is old and therefore good.
The other says-this is new and therefore better."

No trees were killed in the sending of this message. However a large number of
electrons were terribly inconvenienced.

dcollins

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2815
Re: Firewire Jitter Worries ???
« Reply #4 on: February 11, 2006, 01:17:26 AM »

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.



http://www.nanophon.com/tributes/tributes.htm

http://www.nanophon.com/audio/1394_sampling_jitter.pdf

Quote:


With a properly-designed Firewire interface, jitter is the least of your worries.



The guys on the DICE chip seemed to give it a pretty high priority.

DC

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Firewire Jitter Worries ???
« Reply #5 on: February 11, 2006, 09:12:51 AM »

dcollins wrote on Sat, 11 February 2006 01:17



The guys on the DICE chip seemed to give it a pretty high priority.

DC




I believe the chip did this for the benefit of those who insist on decoding a clock from the Firewire line. In any professional audio-only situation there should either be a separate wordclock line or the master clock should come from the interface that has the converters.

BK
Logged
There are two kinds of fools,
One says-this is old and therefore good.
The other says-this is new and therefore better."

No trees were killed in the sending of this message. However a large number of
electrons were terribly inconvenienced.

Gunnar Hellquist

  • Full Member
  • ***
  • Offline Offline
  • Posts: 206
Re: Firewire Jitter Worries ???
« Reply #6 on: February 11, 2006, 09:22:45 AM »

The paper describes a specific protocol, IEC-PAS 61883-6. I have never seen an interface using this protocol so chances are very great that neither does your interface. That protocol transfers word clock on the firewire bus. And what it says is that if you transfer word clock on the firewire bus you can get jitter.

So, don't.

Instead pass the word-clock on a dedicated word-clock line. Leave the firewire bus for data. Problem solved.

Gunnar
Logged
Gunnar Hellquist
unafiliated

mark4man

  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
Re: Firewire Jitter Worries ???
« Reply #7 on: February 11, 2006, 10:21:56 AM »

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.

mark4man


BTW - 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?)  
Logged

PookyNMR

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1991
Re: Firewire Jitter Worries ???
« Reply #8 on: February 13, 2006, 02:03:13 PM »

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.



Bob is right.  BJ explained FW / jitter issues on the Metric Halo forum.  Anyone can do a search there if the desire to find the technical answer.  

Logged
Nathan Rousu
Pages: [1]   Go Up
 

Site Hosted By Ashdown Technologies, Inc.

Page created in 0.026 seconds with 18 queries.