Dan Lavry on USB, Firewire and the universe

[nightscope]

Dan Lavry has a thread on the go at the mo on the Reaper forum.

This clarified a few points for me.



"Hi,

There are 2 aspects to an interface: the hardware and the format aspects. I do not view making digital hardware as particularly difficult or challenging (it is a “walk in the park” relative to micpres, converters…). The standard AES and SPDIF connections for stereo are XLR, Optical (to slink) and RCA connections
For robust performance (for long cable runs, harsh and noisy electrical environment), I prefer XLR connections, for 3 reasons:
1. The power level of the signal is high (typically 2.5-4V into 110 Ohm) offering good noise immunity
2. The signal is balanced -good interference and grounding issue rejection
3. Strong mechanical connection

Next in line for me is the Toslink (optical). It does offer great ground isolation between unit, and it works pretty well at “reasonable” distances. The distance is not the only factor, the bandwidth of the optical transmitter and receiver may limit operation at higher sample rates. Some of the older toslink devices can not do 88.2-96KHz, few Toslinks are specified at 192KHz. But using an appropriate toslink is very viable at a few feet distance.

My least favorite interface is the RCA. It is the most fragile in my experience. One should try to use short well shielded cables. My issues with the RCA (relative to XLR) are:
1. The power level is low (.4V into 75 Ohm, about 1/25 of typical XLR signal)
2. Unbalanced transmission
3. Mechanical connection less robust

Still, I would prefer any of the above 3 connections for stereo transmission, and the reason is not dictated by hardware, but by the format. The AES and the SPDIF formats are well pinned down (defined), they are stable, and as a rule, the various devices interfaced via AES or SPDIF work.

You can not say the same for firewire and usb interfaces. I am very glad to see all the new Mac computers come with built in optical digital audio (both in and out, via mini optical). The issues come up when a computer does not have digital in and out, and also when one wants to have more then stereo.

We are at the middle of the biggest mess! Firewire and USB audio requires drivers, with a ton of compatibility issues such as which driver works with what version operating system, and what gear responds…
The worse part of it: We had a lot of firewire issues, where the time delay through the driver was unpredictable (from “where is the first drum beat” to “my channels do not line up”). After endless failed attempts to solve it, with download after download, and tenth of thousands of complaints on various audio web sites, some marketing guys decided to DIVERT the focus from the real problems into “low latency conversion” issue, which for the most part is B.S. There is less latency going through an AES or SPDIF interface then through a software driver… The latency of an AD is the time delay through a converter. The latency of a “low latency converter” is the delay through the converter PLUS the delay through the driver… That is a whole other subject…

Then there are interfaces based on cards that can be plugged into a computer. As a rule, those are fine. The sad thing is that we do not have a good “standard” interface in and out for audio. USB and firewire, as well as most of the computer tasks, are about moving “ton of data” real fast. But Audio needs the data to be moved at relatively slow but constant rate, and apparently, “bending the software” interface to do what it is not meant to do, is not as simple as one hopes for. The special purpose audio interface cards offer a solution, but it is not free (firewire and usb is already a part of the computer). Those cards receive and transmit AES and SPDIF signals, and handle the computer interface shortcomings…

This is getting to be pretty long. There is much more that can be said. Let me just say, for sending data from say AD to a computer, jitter is NOT and issue. Jitter is important AT THE AD converter, but once the conversion is done (use internal AD clock whenever possible), sending the already converted data into a computer is not too jitter sensitive. Do not confuse conversion jitter with data transfer interface jitter…
Also, though pretty obvious, one want to be sure that the interface does not alter the data in a bad way, such as truncating a 24 bit word into 16 bit…

Regards
Dan Lavry"

ns