Brian's Brain

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.

In addition to researching various audio-tuned CAT5 implementations, I also wanted to explore the premise I raised at the beginning of the article; whether (and if so, when) a conventional Ethernet-based audio network is sufficient to meet application requirements. Today, 100-Mbit Ethernet is pervasive, along with 54-Mbps WiFi. My home office has a Gigabit Ethernet spur, a rapidly growing trend, and enhanced 802.11g variants, along with MIMO (“pre-N”) implementations, promise even higher wireless speeds in the near future. Equally significant, the concept of low-latency QoS for certain types of network traffic is gaining solid footing both in the office and at home, prompted by applications such as online gaming, VOIP, and videoconferencing.

Rogue Amoeba makes a variety of software for Apple computers, including Airfoil, which enables you to stream nearly any audio through an Airport Express wireless adapter (not just content from iTunes). However, the Airfoil documentation warns that you may encounter loss of audio-video synchronization if you, for example, attempt to watch a video on the computer screen while the corresponding audio plays on a home-theater system fed by Airport Express. In a word, the problem is latency.

To a question about what protocol, encryption scheme, and codec Airfoil employs, CEO Paul Kafasis responded, “We have to use what the AirPort Express uses. So the answer here is RTSP, AES, and Apple Lossless.” A follow-up question, asking how Airfoil deals with the unfriendly Ethernet and unregulated 2.4-GHz environments in which Airport Express lives, prompted the following reply, "We don't. We buffer a bit, the Airport Express buffers a lot. And then we hope that everything in-between works. Given that the audio is moved with Apple Lossless, the data rate is something around 87 kbytes/sec. So it's not like trying to move 24-channel PCM audio. As for the unregulated wireless environment, we have to rely on the hardware to figure it out, as there's not much we can do about that in the software.”

Roku Labs makes three models in the SoundBridge Network Music Player series, along with the PhotoBridge HD Digital Media Player and an OEM-licensable Embedded SoundBridge Network Music Module. According to Don Woodward, Roku's CTO, “In our application, we rarely encounter such problems over wired Ethernet.Our products are primarily placed in the home, where, when wired Ethernet is present, bandwidth availability is usually high—much higher than necessary. Most of the audio traffic in this environment is carried out within the home on switched 100-Mbit networks. (Note that I'm discussing the wired case first, 80% of our customers use wireless, which I'll discuss next.)

“Our current SoundBridge line has 10-Mbit Ethernet, not 100. While we are upgrading to 100-Mbit Ethernet in upcoming products, in practice this is not a problem since each SoundBridge in a customer's home only requires at most roughly 2.5 Mbps for the worst case—uncompressed audio at 48 KHz.Since the backbone of the LAN is 100 Mbits, the use of TCP/IP and its associated overhead is inconsequential for us.Many of our customers also enjoy listening to Internet Radio, where the bottleneck is moved outside the home and quality of service is often spotty.

“We overcome many of the reliability problems here by throwing memory at the problem. In practice, what we do is dedicate 4 Mbits to audio buffers. We decode and buffer audio data until the buffer fills up and then continually refill the buffers as they are consumed by the audio system. Since we had memory to spare, and architecturally it was simpler to buffer the uncompressed audio data, that is what we do. In the future, we can with software modifications modify the buffering scheme to buffer the compressed data should RAM become scarce or we desire to increase the amount of audio data buffered.

“This buffering scheme is most relevant to the problems we encounter over WiFi, where even though 802.11b (which is what we do currently) claims to be 11 Mbps, the maximum throughput we've seen with raw TCP sockets is about 5.5 Mbps.As the signal quality degrades, we dangerously approach the 2.5 Mbps number. Fortunately, most of our customers stream compressed audio where 320 Kbps is the upper bound of what they stream. Since our desire is to work with existing music servers (most notably iTunes and Windows Media Connect, as well as other UPnP servers), using proprietary protocols was never under serious consideration. Nevertheless we desired to enable our customers to stream uncompressed audio (either wav or aiff) files over WiFi, so we spent a lot of time analyzing different buffering techniques.

Continued with 'Audio over CAT5: Conventional counterparts, Part II'....