Excerpted from “The relationship between Dante, AES67 and SMPTE ST 2110”
As of September 2019, all pieces of Audinate’s SMPTE ST 2110 implementation were publicly available. This also updates the pre-existing AES67 implementation, making it ST 2110-compatible and allowing for the multicast stream address to be manually determined. Audinate felt the release of ST 2110 interoperability was a good time to share a vision for how Dante and open standards work together. The full version document of this document available at Audinate.com also offers clarity on some myths and misconceptions we hear in the market today, especially around PTPv1 and PTPv2.
A Brief History of Audio Networks
CobraNet (1996) and EtherSound (2001) are widely regarded as the first commercially successful audio networks. CobraNet initially used 10Mbit Ethernet networks; both experienced significant success on 100Mbit Ethernet links. System designers stretched these technologies to address systems of massive scale and consequence, such as convention centers, airports, theme parks, stadiums and live concert systems.
In the years that followed, Ethernet standards critical for media networks evolved and matured substantially. At this time, those who would go on to develop Dante were participating in and authoring documents for standards organizations like the Internet Engineering Task Force (IETF), particularly on topics like zero-configuration networking, Real-time Transport Protocol (RTP), Precision Time Protocol (PTP) and Quality of Service (QoS). From the beginning, Audinate’s development team used their expertise to build Dante on these new and maturing network standards. This led to Dante’s performance: tight synchronization, low latency, expansive scale and adaptability to different network speeds and technologies. For example, earlier network approaches recovered clock from streams of packets. With Dante, Audinate introduced the idea of synchronizing with PTP and then generating the required media clocks. This approach substantially relaxes the requirements on QoS. Thousands of media packets no longer require stringent QoS – only the few sync packets need traffic priority. Because CobraNet and EtherSound predated these standards, their engineers had to develop proprietary methods of addressing these challenges – and these methods did not allow for natural growth as Ethernet matured and provided more bandwidth. As a result, these pioneering systems became frozen in time, and are now considered legacy systems.
As broadcast audio system designs began using network solutions, they needed compatibility with traditional broadcast infrastructure. The natural solution was to put a device on the edge of the network that would offer traditional connections like analog, AES3 and MADI. As more production teams went to network-based solutions, one team’s edge device was often speaking to another edge device on another network. Each networked system was an island; analog, AES3 and MADI remained the universal languages at the “checkpoints” between systems.
Audinate’s View of AES67
As early as 2009, a technical committee from the Audio Engineering Society authored a white paper entitled Best Practices in Network Audio where they began to recognize the “islands of operation” situation. In it, they observed similarities and differences: Since all audio networks used uncompressed PCM data, there was no complex difference in audio data such as codecs or data compression. While many networks of that time used proprietary baseband communications that were not merge-able, Dante and Livewire used standard Ethernet infrastructure. A “cross-platform” connection seemed possible. However, while the data carried in the packets was similar, the stream format was different, as were the synchronization schemes and the control API. In practice, these systems were not directly linkable without significant new development. A new solution would be required to make them compatible directly on the network. In the years that followed, work began on what would become AES67. The standard was published in 2013, updated in 2015 and 2018.
While AES67 is certainly deployable by itself as an independent technology, it is cumbersome and limiting when used as a network solution. Anyone who has used a network solution like Dante would instantly recognize the additional work that AES67 entails and how the experience can be improved by using a network solution like Dante. In the best of circumstances, AES67 often requires technicians to manually set up a clocking structure. Then, to establish subscriptions, they need to “sneakernet” Session Description Protocol (SDP) files around the facility. This process will undoubtedly require technicians to install and manage several utilities and web browser tabs, the combination of which will change depending on the products being connected. But what AES67 does achieve is connectivity among products from disparate audio network solutions. This is the tradeoff – to get audio between network solutions, you inherently give up significant functionality.
Use the right tool for the job
The benefits of product families are well established. There are few things as standards-based as network switches, and yet it is common to choose a product line or brand throughout a network design. The benefits are the same: better consistency, deeper integration. This goes even deeper than just user-friendly interfaces. A network solution like Dante is also more robust. Systems that requires manual set-up will require manual recovery from a failure; systems with automatic set-up can recover from a failure automatically – perhaps even seamlessly. When mix stems, iso lines and intercoms need to be sent between teams on different network solutions, AES67 becomes a viable option. Dante devices can send and receive Dante and AES67 simultaneously. You can have the advanced functionality of Dante’s powerful network solution, yet still have the interoperability of AES67 in your back pocket ready when you need it.
Audinate’s View of SMPTE ST 2110
SMPTE ST 2110 is a suite of standards and specifications. While its primary focus is on the transport of video, it also addresses the audio element of the stream. Because ST 2110 addresses both audio and video, some naturally assume the standard brings the same benefits to each discipline. While ST 2110 is interesting to the audio side, the reason for adoption is completely different and understanding this is important for more effective system designs.
The audio interest in SMPTE ST 2110 is less revolution, more evolution. ST 2110 audio streams are essentially a carbon copy of AES67 – with a few parameters tightened down. This wasn’t an accident. To prevent competing universal bridging modes in the same industry, representatives from the AES technical committees that developed AES67 collaborated with those on the ST 2110 technical committees. So, everything said about AES67’s role applies to ST 2110, at least as a starting point. For audio teams, the appeal of SMPTE ST 2110 is largely for integration with the video world. In the past, sometimes video teams spoke the language of audio with AES3 or MADI connections, other times audio teams had to speak the language of video with SDI embed/de-embed devices. Since audio teams are already using network technology and ST 2110 is so closely related to the work already done for AES67, the adoption of ST 2110 was a manageable addition to streamline links to video teams.
More to come
It is noteworthy that a variety of industry organizations are attempting to enhance ST 2110 by developing more linked standards and specifications. The JT-NM roadmap details development that will improve the experience over the existing AES67 or ST 2110 standards. This progress was summarized in the “pyramid” chart (page 44) by the EBU, showing that most of this is still under development. The transport element and synchronization tiers have reached a point of stability. More recently, SMPTE 2022-7 was referenced for redundant network configurations, deemed stable and has been included in Audinate’s ST 2110 implementation. Other proposed features are far less mature at this point. The current JT-NM roadmap shows NMOS elements (IS-04 discovery and IS-05 connection management) gaining significant adoption in the time period between Q3 2018 – Q2 2019. (JT-NM, 2018) This certainly seemed premature as significant challenges with NMOS interoperability and stability are being reported in the field.
AES67 and SMPTE ST 2110 Implementation
Audinate has publicly expressed a goal of supporting AES67 and SMPTE ST 2110. No official comment can be made at this time about incorporating NMOS – the evolution and adoption of standards are obviously unpredictable and driven by market demand. Moving beyond IS-04 and IS-05, the rest of the pyramid has hardly been addressed, yet. In the future, SMPTE ST 2110 supporters hope to tackle system configuration and monitoring, as well as network security features. This discussion reinforces the concept that network solutions are a different breed than interoperability standards. Everything in the JT-NM roadmap is already addressed by Dante with Dante Domain Manager today with real, mature products. And since Audinate supports SMPTE ST 2110, Dante products can offer the best of both worlds – the power of the network solution and the interoperability of the open standard.
Choose a Mode: AES67 or SMPTE ST 2110
To use AES67 or ST 2110 on Dante devices, the user will choose one open standard to support. The significance is not about compatibility – AES67 and ST 2110 can be made to be compatible. The choice is more about how you want to work. The functionality and requirements of each mode reflect the requirements presented by the standards organizations in their respective interop events. As work began on SMPTE ST 2110 functionality, it was very clear these groups wanted far more depth of control than the early users of AES67 desired. Offering two modes seemed to be a better approach than requiring existing AES67 users to take on additional responsibilities and learn significant new controls as the result of a natural firmware update. Thus, the two modes were born. It should be noted that for AES67, Dante Domain Manager is optional. For SMPTE ST 2110, the depth of configuration called for a central management solution offered in Dante Domain Manager.
Network solutions for the audio world have been in use for over 20 years. All were developed with a customer and a use-case in mind, considering not only the fundamental technology but also the tools to effectively manage the workflow. Dante represented a turning point for audio networks. It is built on standards, which allowed the system to achieve new levels of performance and scale. Further, Dante was developed with a networking workflow in mind, offering more than just the tools to create subscriptions. Dante provides a comprehensive solution to deploy, manage, secure and maintain the system.
Interoperability standards like AES67 and ST 2110 evolve differently. Their goal is to provide a blueprint for a network stream that can be implemented amongst multiple providers. Implementations typically remain primitive, often requiring manual operation of common processes. Manufacturers must pour work into duplicative code bases that need to be tested for interoperability. However, interoperability standards are a viable option to move data between teams that are built on network solutions. It should be noted that the ST 2110 opportunity is entirely different for the audio and video disciplines. For video teams, the opportunity to move from an aging point-to-point SDI connection to an IP based solution represents a massive step forward. But for audio teams, even with the NMOS on the horizon for ST 2110, network solutions like Dante offer far more maturity and functionality for the system deployment, maintenance and security. Given all this, our position is to draw a circle around an audio team and keep them to one network solution. When a connection is needed to a team on a differing network solution – or to a video team based on ST 2110 – Dante’s support of AES67 and ST 2110 interoperability standards are available to communicate directly on the network.