This post is a supplement to my article 'CAT5 tracks: Audio goes the distance, reliably and on time' in the July 7, 2005 issue of EDN.

The heady, early days of any booming new application are invariably marked by the emergence of numerous technology implementations. Whether for technical reasons ("Existing approaches don't ideally address my specific needs"..."I can design something that does this much faster/cheaper/lower power than the existing approaches do") or business-related motivations ("I don't want to pay a license fee and royalties to someone else"..."I want others to pay me license fees and royalties"..."They're my competitor, I don't want to enable their further success"..."I want customers to buy all of their equipment from me"), the result is a plethora of incompatible approaches that mostly motivate customers to keep their wallets in their pockets!

Inevitably, however, a few leaders emerge at the expense of the others—the outcome of factors such as deep pockets, key design wins (for example, PortalPlayer's presence in the original Apple iPod), and skillfully crafted licensing and partnership agreements. In addition to the companies and technologies discussed in the main article, the following companies (and, likely, others) currently participate in the audio-over-CAT5 application space with proprietary approaches:

• Aviom's A-Net and upcoming A-Net Pro;
• Axia Audio's Livewire;
• BSS Soundweb's SW9000-series (note that the Soundweb-London BLU-xx product line employs CobraNet);
• Hear Technologies' HearBus;
• Intelligent Media Technologies' SmartBuss; and
• Lab.gruppen's NomadLink (per its late-2003 licensing agreement with Cirrus Logic, the company appears to be migrating to CobraNet).

Industry standards bodies can help drive technology consolidation, although their inevitable slow progress (they are comprised of competitors, after all) sometimes results in their simply rubber-stamping products that have already achieved de facto standardization (and, in some cases, are already obsolete!). AudioRail founder Garth Wiebe points out, “The AES (Audio Engineering Society) developed MADI (Multichannel Audio Digital Interface), also known as AES10, in the 1992 timeframe. MADI sends up to 64 channels of up to 24 bit audio, using a time division multiplexed scheme on a 75 ohm unbalanced, single-ended coaxial transmission line, with a voltage swing of 0.3 to 0.6V peak-to-peak. MADI is used to this day, but is not very common.”

“For many professional audio applications, a round-trip time from the microphone through the mixing desk and back to the headphones of no more than 3 msec is required. Allowing 0.5 msec each for conversion from analog to digital and back again, it follows that the network connections to and from the mixing desk must have a latency of less than 1 ms each. For distances of more than about 200 km, the transmission delay alone will exceed 1 msec, but within a metropolitan area the transmission delay should be no more than 0.25 msec (equivalent to about 50 km), leaving 0.75 msec for packetization, queuing within switches, and resynchronization within the receiving equipment. ATM was chosen because it is able to meet these timing requirements, even in large and heavily loaded networks, whereas IP can only meet them under very special circumstances.

“One important feature of AES47 is the small payload size of the packet (or cell), 48 bytes. A packet cannot be transmitted until enough audio samples have arrived to fill it, so when sending 44.1kHz 16-bit stereo, the ‘packetization time’ for a 48-byte payload is about 0.27 msec. Using RTP over IP with this payload size would mean that more than half the packet is overheads such as the addresses and headers; with a larger payload size the packetization time becomes correspondingly larger.

“AES Standards project X143 is developing the carriage of AES47 (and other ATM traffic) over Ethernet links, thus taking advantage of the best features of both Ethernet and ATM and allowing AES47 to be used at up to 1 Gbps over CAT5. The format includes the Ethernet MAC layer so it can be used with standard Ethernet interfaces in PCs etc, and (b) connections between sites via wide-area ‘Ethernet with QoS’ services.

“The protocol includes synchronization facilities that allow latencies and delay variation to be tightly controlled, thus providing even better performance than on standard ATM networks. This also reduces the amount of buffering required, which can lead to important cost savings in consumer equipment. Equipment can auto-sense whether the ATM format is supported on the network, so that it can use AES47 if it is available but fall back to other protocols such as IP otherwise.”

Continued with 'Audio Over CAT5: Proprietary alternatives and standardization efforts, Part II'....