Dante vs AES67
Updated: Jun 17
Audio Networking is becoming increasingly popular. It started in the 90’s with CobraNet, but first took off with Audinate’s introduction of Dante in 2006. The key to Dante’s popularity is the ability to easily transmit and manage low-latency, high quality, multi-channel audio over standard Ethernet. A growing number of professional AV products not primarily designed for audio, including AV over IP solutions, do however not incorporate Dante support, they instead offer integration with DSP's and other 3rd party equipment through AES67. So what's the difference between these standards, and what are the implications to the integrator and the end users?
The popularity of Dante has grown steadily over the past years and Audinate now have 438 licensed Dante OEM’s (2018), and more than 1,600 products are available on the market. Dante isn’t the only option though; Q-LAN, Limewire, RAVENNA and WheatNet are other technologies all designed to transmit low latency audio over IP. The problem is that these standards are mostly incompatible and non-free. If an AV manufacturer would like to implement audio streaming using these technologies, it typically involves licensing fees, which in the end increases the cost of the product to the end user. There is a possible solution though; AES67 enables all of these different technologies work together, and it's free! Too good to be true? As with most things free it comes with a few limitations.
AES67 is an interoperability standard for professional, low latency audio over local area IP networks. The standard was developed by the Audio Engineering Society (AES), and first published in September 2013. It was designed around existing protocols, which means it shares characteristics with both Dante, RAVENNA as well as other audio streaming technologies. Existing technology providers who wanted to support AES67 were free to either implement interoperability as a special mode, or transition to use the features specified in the AES67 standard as the native mode. AES67 was never meant to replace Dante, or any other existing technologies for audio transmission. It was designed to act as a bridge, allowing communications between systems designed on different technologies.
The latest version of the standard is AES67-2018. The standard defines:
• Media Clock
• Encoding and streaming
• Session description
• Connection management
One of the features missing on this list is discovery, and there seem to be a bit of confusion on what this means. While I frequently hear people say, “I don’t like AES67 because it doesn’t offer discovery”, AES67 does indeed recommend the use of discovery protocols. The challenge is that the specification offers multiple alternatives, including Bonjour, SAP and others. People implementing AES67 in a Dante ecosystem would naturally prefer SAP, which is the standard used by Audinate, but Ravenna users would instead want mDNS – also known as Bonjour. This means that devices supporting AES67 might use SAP, mDNS or no discovery at all. Lately SAP does seem to be the more popular choice though, largely helped by Dante's market share. This allows any AES67 enabled device supporting SAP to be discovered and controlled from Dante Controller. For devices supporting mDNS or lacking discovery support, RAVENNA offers a handy tool called RAV2SAP providing session announcement translation between RAVENNA and SAP-based devices. AES67 also lacks control and diagnostics capabilities. Dante offers some very useful tools for monitoring clock accuracy and latency, and pin code protection for security is also not available for AES67.
The big question is if what we can expect from audio quality and robustness when AES67 is integrated in a Dante system.
Looking at the AES67-2018 standard, it doesn’t specifically mention latency, but instead uses the term packet time. After reaching out to Audinate, they did confirm that their current end-to-end latency in AES67 mode is fixed at 2 times the packet time; 2 ms, but will in fact be increased to 3 ms with firmware 4.2 to ensure compliance with SMPTE 2110. Meanwhile Dante, (depending on the device), offers latency settings all the way from 150 µs up to 5 ms. AES67 integrated in a Dante system is also limited to multicast only, and 24 bit audio at 48 kHz sampling rate.
Other compatibility concerns worth mentioning are the issues with synchronization and QoS. Dante uses PTP for synchronization, while AES67 requires PTPv2. Audinate has later added PTPv2 support to Dante to ensure compatibility, but if you are using an external clock, make sure this device supports PTPv2. There are also conflicts related to QoS, but this is also manageable. Allen & Heath has a great document with some good explanations and guidelines.
Integrating devices with AES67 audio into a Dante application comes with a few limitations. The key issues are a fixed latency and audio settings, lack of monitoring and diagnostics tools, and possibly having to use additional software to manage discovery if the devices aren't using SAP. Weather these issues are manageable or not, largely depends on the application. Regardless, AES67 is a huge step forward in integrating different audio technologies in the same network. Moreover, it also becomes a viable option for manufacturers looking to add interoperability for products not primarily designed for audio - without using 3rd party technology.