Sending audio over ethernet networks has changed significantly since introduced in the mid 90s. Developed by Peak Audio in 1996, CobraNet® was one of the first protocols to see widespread commercial use. Twenty five years later, you can still find CobraNet in active use around the world. More recently, Audinate's Dante® was developed in 2006, and has become one of the most prevalent standards in recent years. (Click Here for a list of AtlasIED's Dante enabled devices)
One of the benefits of these protocols is that they usually work out-of-the-box, without requiring special network configuration. However, as the complexity and size of a system increases, extra care must be taken to ensure that the network can reliably and quickly get the digital audio to where it needs to go. This applies to even a smaller system that spans multiple network switches, such as those in large buildings/campuses.
A key feature of any digital audio protocol is the common clock source used by all devices. Similar to non-networked audio and video standards (such as AES3/AES50, SDI, etc.), the clock ensures that all the devices are operating in lock-step, guaranteeing that the audio output is synchronized. Without a common clock, the audio playback could become delayed or distorted, even if the network is performing perfectly.
CobraNet is a fairly simple protocol, developed to work with the network technology available at the time. The clock source for CobraNet is done by a single device (called a conductor) sending 750 Beat packets a second to the entire network. All the other devices (called performers) synchronize their clocks to those Beat packets. Audio traffic may go directly between devices, or be broadcast to the entire network. The end result is that a large number of small packets are sent through the network continuously. Some network switches detect this traffic as a network 'flood', and try to control the flood by slowing (rate limiting) it down. If this occurs, CobraNet audio may sound distorted, or not play at all.
Dante is more complex, as it uses multiple protocols for different functions. Device discovery uses 'Multicast DNS' (MDNS), clocking is provided by the 'Precision Time Protocol' (PTP), and the audio is handled by Dante itself. All of these protocols are distributed on the network as 'Multicast' traffic.
In an unconfigured network, most switches will simply broadcast this multicast traffic to all devices, similar to how CobraNet functions. On large networks with many devices, all this multicast traffic can overwhelm some devices and switches. To address this issue, each device uses a protocol called 'IGMP' to control the flow of Multicast traffic. This greatly reduces the amount of traffic across the network, and allows for larger systems to exist.
Another network technology that's used by Dante is QoS (Quality of Service). This is used to ensure that time sensitive traffic is switched before other, lower priority, traffic. The PTP traffic used for clocking is highest priority, followed by the Dante audio traffic. QoS is important when the audio traffic shares its network with other types of traffic, as it's the only way to guarantee the audio is put at the front of the queue when there's network congestion.
Most manufacturers provide documentation on how to properly configure the network for digital audio. In some cases, there are particular network switch brands and models documented that should be avoided, as they cannot be configured to reliable handle the digital audio. As networks get larger and more complex, making sure the network is configured properly is critical for success.
Historically most digital audio networks were simply kept isolated from other networks in the customer's environment, which helped guarantee performance. Today, most customers will never consider having a physically separate network just for audio. As a result, the configuration of the network falls to the customer's IT/Network team, who rarely have any experience dealing with digital audio over a network. Multicast, IGMP, and QoS are all technologies that are infrequently used, especially on smaller networks, so it's important to involve and educate the customer's network team early in a project.
Authored by: Tad Heckaman, Sr. Network Engineer, AtlasIED