DIYHiFi.org

Does the firewire protocol have less inherent jitter than USB 1 or 2 with regards to audio? Someone suggested to me that it has 10 times lower jitter.

If this is the case, why aren't there many (any) Firewire DAC's available outside the recording industry (these are "external sound cards" more than just DAC's), where they are as common (or more so) than USB DAC's/soundcards?

If converting to SPDIF for use with an existing DAC, is ther any advantage to Firewire over USB? There are zero Firewire to USB converters available (that I can find).

Thanks

The following applies only to devices using protocols defined in recognized standards. There are devices on both buses that implement their own protocol, in which case the data bus' effect on the timing will be entirely determined by the protocol in question. It's entirely possible to develop a protocol for either USB or Firewire that doesn't introduce any timing jitter at all.

First, USB (in USB Audio Class devices) is generally used in a mode where the clock is recovered based on the timing of the data packets, which are specified to be sent by the host PC exactly once every 1ms. Obviously there is lots of room for jitter here, as the timing is software controlled and the bus is not really designed for low jitter, especially where hubs and the like are involved. The specification does provide for a mode where the playback clock is slaved to the USB device and data is delivered as requested, but this mode has seen very little commercial support. It has only recently (with Vista, I believe) been included in Windows, and as far as I know there haven't been any commercial devices using it. Most professional USB gear implements a custom protocol for this and other reasons. Most of these slave the playback to the clock in the USB device, in which case no jitter will be introduced by the USB connection.

Firewire (under IEC 61883-6), as far as I can tell from the available documentation (which isn't much) is much better for audio. It seems like some kind of timecode system is used for clock recovery, with the sender sending the exact time each sample should be played back. This would allow for a local clock at the device and some control electronics to direct the data to the DAC at the exact moment specified by the host PC. It must be more complicated than this though, since a simple system as described won't tolerate any clock skew between the two clocks, and obviously that can't be the case. The standard does seem to account for jitter though, and the Firewire bus itself was designed specifically for transferring realtime video and audio in a professional setting, so I suspect it is well designed in this respect.

10 times lower jitter? For a generic USB audio class device I'd say it introduces infinitely less jitter. That doesn't mean a random Firewire device is necessarily better for jitter than a random USB audio class device. Devices using custom USB protocols & drivers are in most cases going to be equivalent to Firewire.

Unfortunately for us DIYers the mass market just doesn't care much about Firewire audio, which makes it relatively inaccessible to us thanks to a lack of products (and possibly licensing issues), and USB audio is garbage for high quality audio without lots of custom R&D, which is really hard to accomplish in a DIY setting. I assume it's not seen often/ever in audiophile gear for the same reason; the R&D cost is just too high for it to be worthwhile - it's easier, more profitable and more flexible to accept an S/PDIF source than a crippled PC input.

If you want an OTS solution, either a pro USB or Firewire soundcard with S/PDIF out will serve you fine, as far as I know they all slave the playback clock to the device. They still need a proper internal clock (which is a feat in itself), but the situation is still better than recovering a software generated clock from the data bus. Most will allow you to slave the clock to the S/PDIF input as well, which will allow you to do away with jitter issues on S/PDIF too - if your DAC supports it. The DIY and cheap USB to S/PDIF converters pretty much universally use the TI PCM270x series chips, which limits you to USB1.1, 16bit/48khz and crummy USB audio class clock recovery. You probably don't want those.

Firewire took the place in professional recording systems for its traditionally high bandwidth and low latency. In home audio reproduction these were not the issues, and in this regard USB 1.1 was mostly sufficient. The USB has been improved regarding the speed (brand new USB 3.0 supports up to 4.8Gb transfer rates), but latency still can limit its usability in pro applications.

As error404 has already told, unless you slave PC to the DAC, in which case it is the local DAC clock that determines the result, the USB DAC will retrieve sampling clock using 1ms packets as a starting point. There is no other way, since the USB protocol itself is a "clockless" one. Resulting jitter will ultimately depend on quality of used PLL or/and data buffers.

As for the Firewire jitter performance understanding, Julian Dunn is still great help.
http://www.nanophon.com/audio/1394_sampling_jitter.pdf

Interesting stuff.

So, is it imposible for me to slave my PC to my Xindak DAC-5 (only has 2 SPDIF inputs - coaxial & Toslink)?

I was thinking that the JAVS DAC-1 may be a good USB solution. It would be a stand alone DAC for use with my laptop when working away and then could be used as USB to SPDIF converter when at home (into the Xindak). I was thinking I could also connect my CD player into the SPDIF input of the DAVS, so that both my PC and CD player would share the Coaxial input on the Xindak (swichable on the DAVS).

Is this a bad idea?

To slave your PC to your DAC your DAC would need an S/PDIF clock output. It's probably possible to mod your DAC and add an S/PDIF transmitter for this purpose, but it's not possible otherwise.

Guys,

If you use the Native Firewire Audio protocol and the Iso Adaptive USB then you run into the same problem with both. The computer is controlling the audio serial rates and changing them on the fly so they match.

In general the Oxford Firewire stuff had terrible jitter specification of over 1000ps. Most of the even poorly done PCM27/29xx parts are less than that.

All PRO market Firewire products use bulk mode and require drivers to be written for the host computer. These work async to the computer so it is merly the intrinsic jitter of the topology that they use.

I still think Async USB is the best bet as the os supports these natively and you are not tied to custom drivers and hardware. Though you do have to do allot of programming to get it too work and you loose allot of hair reading those USB specifications and trying to figure out what is going on:

http://blog.stereophile.com/rmaf2008/101408wavelength/

Thanks
Gordon

There are two advantages of current Firewire designs, and those are:

1) low latency - necessary for studio work
2) 24/192 support

Firewire has gotten a recent following in high-end audio circles due to a few devices based on the TC Applied Technologies DiceII chip, which is not asynchronous, but does have a clever feedback PLL system called "JET" that produces fairly low jitter compared to most USB interfaces. The jitter of course is a function of the basic clock to begin with, as well as the implementation of the circuit, power systems and board layout.

Either Firewire or USB have the potential for extremely low jitter if they are implemented asynchronously, as Gordon has done. There are still plenty of pitfalls to achieving low-jitter, but at least this has the best chance of it.

I suspect that USB will take the lead again in 2009, when more asynchronous interfaces are available, and 24/192 is supported.

Steve N.
Empirical Audio
Master Jitter Magician

I wonder if the JAVS DAC-1 Overture (and UHF-1) have achieved low jitter? I don't read Korean, so I have no idea! The fact that they both use well specified clocks at least hints that they are at least considering jitter.

Has anyone heard of the Tenor TE7022L usb audio controller that is used in the JAVS units?

Steve,

Paul Miller tested a dac using the chip set and said it had over 1000ps of jitter. This was also the down fall of the Oxford setup even though their second generation was allot better than their first they still bailed on the idea.

The second problem is the ASYNC mode in firewire is not supported by any os.

But the biggest reason to dump the idea of firewire is because everyone in the computer industry has already started the fall. Apple has started to dump firewire and they are the ones who made it famous.

All the pro companies use Firewire and USB in block mode. Someone years ago came up drivers and hardware model and everyone bought the program. Now that firewire is going away they are all running out to find new USB offerings.

Since in all os's the computers work fine with USB to 210K fs rate and they have async mode it makes all the sense in the world to go that way.

Steve there are a ton of chips that do 24/192 USB but again all of them would require programing. I have been working with TI for months now on some new stuff that should make 24/192 pretty easy to achieve.

Thanks
Gordon

Is it possible to have some anticipations on this?

Thanks
Andrea

Andrea,

Same thing I have been asking.

Thanks
Gordon