IPfocus - IP UserGroup

IPfocusBack to basics AudioTechnology explained for mortals:Inevitable delay when distributing Audio over IPWhenever you transport audio over an IP network -this is true for every vendor and every technology,you will incur a delay. This is unavoidable. Why ?Audio needs to be sampled into the digital domainat the encoder, and packetized to keep the networkload in check. Depending on the application, codecused and the requirements, the amount of samplescollected before sending will be between 1ms androughly 100ms. This is the delay introduced by anoptimized encoder, assuming no further processingor buffering, with PCM or low computationalcompression algorithms.With MP3, an additional delay will be introduced,due to the time the processing of the collectedframe into a compressed MP3 frame takes. WithMP3, expect an additional processing delayintroduced by the transmitter of roughly 20ms-60ms.Transmission over the network: The block/frame ofsamples now needs to be sent over the network,potentially fighting with other traffic for bandwidth.On a local LAN, the delay will typically be quite low(msecs maybe), but beware .. if there is"sometimes" a fight over bandwidth/buffering in aswitch or router, you may see average very lowdelays but the delay incurred by some packetscould be substantially higher. The differencebetween the fastest and the most delayed packet iscalled "Jitter". For example, if the transmission ofan audio block over the network takes a min. of5ms and in the worst case 200ms, the "jitter" willbe 195ms.Reception at the decoding side: The D/A at the endof the data flow in the decoder must be constantlyfed with samples at the sample rate. As thesamples do not come one-by-one over the network,a buffer is unavoidable.The buffer must be configured to a level which ishigher than the worst jitter so that the D/A endnever runs out of data. It typically makes sense toadd a bit more to the buffer to consequently avoidan "out of samples" situation, as this is an (audible)fault, such as a chirp.With MP3, the decoder processing must take placebetween the network buffer and the D/A. As thedecoding functionality needs to work on the wholeMP3 frame and cannot really start doing this beforeit is delivered complete, the network receivingissue 27_28buffer must contain a full MP3 frame before thedecoding can be started. And as the decodinghappens in "blocks", an output buffer "behind" thedecoder for samples again needs to be established.The last addition of delay is not really necessarytechnology wise, but a fact in Barix devices. We usea Main CPU for network tasks and a DSP driving theD/A, which turns the samples back to analog audio(and has a sample buffer implemented). The DSP isnecessary for MP3 (and AAC etc etc) decoding, forPCM it mainly works as a pass-through. Theinterface between the main CPU and the DSP isquick and does not need much additional buffering,however, the DSP has an input buffer also.DSP Sample buffer: This buffer can introduce asignificant delay for low bitrate/sample ratestreams. Depending on which Barix product youuse, there are different DSPs "under the hood",with different sample/output buffers. As such, theAnnuncicom and Exstreamer 500/1000 devicesproduce a much shorter delay than Exstreamer100/110/200 devices.So, at the end you have several sources introducingdelay, with the buffering for network jitter beingoften the most significant one, but a "base delay",depending on sample rate, encoding format etc isalways present. As you can figure from the aboveexamples, if you have the bandwidth, it often makessense to configure higher sampling rates andbitrate streams, as that will effectively lower thedelay due to the fact that the constant (byte wise)buffers in the chain have a smaller through delay.Overall, with the Exstreamer 1000/500 and theAnnuncicom products, an end-to-end delay ofaround 50ms is currently the lowest. The softwarehas not been optimized for very low delay.However, with optimized software, you can get thedelay down to well below 20ms - that has beenproven in our labs (for a specific project). We are inthe process to bring this number down further,obviously, this can only be done by sending manymore blocks over the network, so you need morebandwidth.By sending samples every 1ms (1000 times persecond !) over the network, delays down to about5ms should be achievable with an optimal networkwith almost no jitter. We are currently testing outwhat is possible in the labs .. so stay tuned !Any IP codec of any manufacturer is bound by theneed for packetizing, and buffering against jitter. Ifyou can show me a device from any manufacturer,which routes Audio over IP, works over a networkwith 50ms jitter, sends less than 100 packets persecond and introduces an end-to-end delay frominput to output of less than 10ms, thismanufacturer has defied physics and i will be happyto buy you a beer and work for them.About Barix AGBarix AG, headquartered in Zurich Switzerland,specializes in research and development of state ofthe art IP based communication and controltechnology. Barix products are stand-alone andable to remotely connect worldwide over standardnetworks / Internet offering new and improvedsolutions to the professional audio distribution,communication and automation industries. Barixproducts provide solutions in audio over IP (audiodistribution and monitoring, communication,security) and automation (remote control,monitoring and maintenance).(www.barix.com )