Andreas Hildebrand is senior product manager at digital media technology company ALC NetworX. From that perch he has been closely involved with development of the company’s Ravenna audio over IP technology. He recently conducted a session examining the AES67 audio over IP technology at the NAB Show.
TechBytes: What is AES67?
Andreas Hildebrand: Shortly after the introduction of Ravenna, the AES came up with the idea of working on an interoperability standard for high-performance audio over IP distribution. The motivation was based on the fact that at that time some IP-based networking solutions were already in existence and deployed, but despite being based on IP and in most cases also using same protocols and similar technologies, none of these were interoperable. Hence, the AES X192 Task Group was formed and worked for nearly three years on a designated interoperability specification. The goal was not to define yet another new solution, but to evaluate already existing technology and solutions, find their commonalities and finally define a standard specification which would allow all existing solutions to participate in this interoperability scheme, with just minimal refinements or extension work.
Needless to say, we had massive interest in participating in this work and advancing it to a full working standard. When finally published September 2013, we found that Ravenna technology was in all major aspects already in line with the new AES67 standard; thus, Ravenna was the first technology which was already AES67-compatible straight out of the box.
TechBytes: So what are the keys to AES67?
Hildebrand: Here’s a quick look at the main ingredients of AES67:
- Synchronization — required to have all participating nodes “in tune”: The well-proven industry standard IEEE 1588-2008 (also known as PTP) is utilized to accurately distribute absolute time among all nodes (down into the nanoseconds range), from which a precise media clock can be generated locally.
- Network and Transport — define the protocols and network layers for data transport: AES67 utilizes IPv4 and requires unicast & multicast support. Audio data is conveyed in packets based on the well-known RTP protocol (see RFC 3550& 3551)
- Audio Data Encoding defines which audio formats have to be supported: the Task Group determined that in professional environment 16-/24-bit PCM-encoded (linear) audio data @ 48 kHz is mostly being used. Devices need to support streams with up to eight channels (to accommodate surround signals). Since in select applications 44.1 kHz and 96 kHz are also being used, AES67 recommends that these sample rates should also be supported.
- The packet setup describes how many audio samples are stuffed into one RTP packet. Since low-latency was one of the goals, the Task Group decided to mandate for 1 ms packet time, which translates into 48 samples/packet (@ 48 kHz). To accommodate even shorter, but also more relaxed latency requirements, recommendations for 6/12/16/192 samples/packet were given.
- Quality of Service: In order to achieve expedited forwarding of AES67 packets through the network, Differentiated Services (DiffServ) needs to be in place. Devices need to support and tag AES67 packets with at least two or more DSCP priority tags, depending on their type (PTP packet must receive highest priority, RTP packets need to be prioritized against any other [best effort] network traffic).
- Connection management is achieved with the help of SDP and SIP protocols (the latter for unicast only): while SDP describes all necessary stream parameters to connect to and decode an RTP stream, the SIP protocol (well-known from the VoIP telephony world) provides means for connection setup in case of unicast (as such, AES67 in unicast mode is pretty similar to the VoIP mechanisms, albeit with much higher and faster performance).
TechBytes: Why is AES67 important to radio broadcasters?
Hildebrand: As I noted before, there were several complete, but incompatible IP-based solutions around for some time. This imposed practical limitations to broadcasters when selecting gear for their operations. Consequently, broadcasters were often reluctant to switch from broadly available analog or digital gear to a network-based approach. With AES67 there is now an interoperability standard for IP-based networking available which is comparable in scope and impact to the well-known and universally supported XLR, AES/EBU or MADI standards. From now on, broadcasters will again have the freedom to choose their desired gear based on performance, features and price, not depending on the underlying networking/connectivity solution.
TechBytes: We’ve heard a lot of terms associated with audio over IP – Ravenna, Audio Video Bridging, Dante, Livewire, WheatNet-IP and others. What are those and how do they relate to AES67?
Hildebrand: It is important to understand that AES67 is an interoperability standard, and as such, is lacking important features and functionality of complete networking solutions, like full system integration, advanced connection management, advertising and discovery as well as further vital functions like control (i.e. GPIO/tally transport, etc.) and solution-specific features. Also, as interoperability is the main target here, the signal data formats which need to be supported under this standard, are very limited (but nevertheless very useful in a professional audio environment). The individual solutions usually offer much more format flexibility to accommodate the diverse requirements of a wide range of applications. For example, Ravenna offers sample rate support up to 384 kHz, full AES/EBU transparent signal transport and lowest possible latency options to enable MADI over IP transport. Consequently, AES67 will not replace the existing solutions, but ensures that connectivity and synchronized stream exchange among gear adhering to different networking technologies can happen.
TechBytes: Where is AES67 at this point? Is it being used in the field?
Hildebrand: AES67 was published in September 2013. Since Ravenna was already been compatible with AES67 at that time, basically all Ravenna installations could use AES67 (although — as explained above — in most cases other formats with higher performance features have been chosen). A first all-AES67 pilot project was installed by Finnish company Jutel in a restaurant in Oulu, Finland, in April 2014 and has been running flawlessly since then. The installation included gear from Jutel, Axia, ALC NetworX and 30 IP-enabled speakers from Genelec. The AES67 streams are running on a common network infrastructure utilizing a standard network switch from Cisco.
Other, non-Ravenna companies have now announced their support for AES67, including Axia (Livewire+), Audinate (Dante), QSC (QLAN) and others. I expect to see more AES67-based installations coming up throughout this year, and I envision a significant market penetration of AES67-enabled gear within the next 2–3 years.
Further information on AES67 (and Ravenna) can be found in white papers on the Ravenna website.
