Audio Over CAT5: Conventional counterparts, Part II

Continued from 'Audio Over CAT5: Conventional counterparts'….

“We ended up taking a two-stage approach where we pre-buffer a short amount of audio (about 4 sec worth) before engaging playback. If at any time during the stream the audio buffers drain, we rebuffer (about 20 seconds worth of audio) before re-engaging playback.We've found through empirical study that this scheme works well to counter WiFi interference (from phones and microwave ovens, etc), when the baseline data rate hovers around 2.5 Mbps.Since our units are statically placed, (not moving around the home), this policy is workable. This scheme also helps counter interference on slow networks (1 Mbps) when streaming compressed audio.

“Our customers are extremely happy with the WiFi performance, reporting better performance than other systems that use protocols like UDP with less overhead.I have to smirk sometimes when I consider the abundance of memory in our system and how only a few years ago having 16 Mbits of RAM in an embedded system would have been considered unthinkable.

“Let me also discuss compatibility for a moment.From the networking perspective compatibility has been an ongoing struggle for us.We've found many of the inexpensive routers available on the market have given us trouble in a number of areas….Basically we've found that, in particular, the DHCP implementations in routers vary greatly….In our case, we have a TCP/IP stack whose implementation is written to the letter of the specification, but in the real world we've encountered many systems that are not quite in spec.As a result we've spent a considerable effort just making our stack compatible with the plethora of devices our customers own.

“This might not be something that would be required in a proprietary system….For us, we've felt the effort is worth it, since our philosophy is to continue to develop software that plays in an open, varied environment. Another big compatibility area for us has been with WiFi.Vendors' proprietary extensions and implementation quirks often give us the same sorts of problems I just alluded to with DHCP.”

On the issue of latency, Woodward notes, “Latency is an issue when you try to keep two streams in sync. The audio/video case is difficult to do and in that case you really have to have an out of band protocol between the two renderers to maintain synchronization. The same is true for audio if you want accurate room-to-room synchronization, for example. Some players support multi-room sync but rely on the network protocol to deliver the packets reliably and with sufficient performance.

“In our case, we're working on an out of band (TCP or UDP based) communication protocol for SoundBridge that will allow multiple SoundBridges to sync to the same stream by each reading their own copy of the audio data from the server, buffering it, and waiting for the 'go' signal from the master SoundBridge to things start on time. As long as none of the buffers (big buffering helps us here as well) fully drain on any of the units, this start synchronization is sufficient to maintain sync for 99% of the cases—the odd case being an extremely long (for example, 48 hours) stream that is intended to be played synchronously on multiple units and the clocks on the multiple units vary to the point where they get pretty out of whack with each other.

“I haven't done the math fully, but I remember taking a first stab at it and coming up with 48 hours with crystals pretty far out of tolerance, temperatures high, etc. For during-play correction, the out-of-band protocol just has to continue to send time-stamps from the master and the slaves have to duplicate or drop samples occasionally.This again is where a more proprietary solution might have an advantage, but again with our large buffers we mask out most of the problems we might encounter.”

For an in-depth explanation of the difference between TCP and the streaming multimedia-tuned UDP, as well as of higher-level streaming protocols such as RTP, RTSP and MMS (versus the more common HTTP), see Nels Johnson's article “Network Video Protocols” in DV Magazine's May 2005 issue. What applies to video also applies to audeo, with the qualifier that in the latter case the bit rates are (thankfully) usually lower!