AES67 FAQ

What is AES67?

AES67 is a standard to enable high-performance audio-over-IP streaming interoperability between the various IP based audio networking products currently available, based on existing standards such as Dante, Livewire, Q-LAN and Ravenna.  It is not a new technology but a bridging compliance mode common to all IP-Networks; an interoperability mode you can put an AES67 compliant device into, on any participating network.  AES67 operates over standard layer 3 Ethernet networks and, as such, is routable and fully scalable, like any common modern IT network.

AES67 was published on 11 September 2013, a copy of the standard can be downloaded from the AES standards website HERE. There is no charge for AES members, non-members must pay $50 for the download.

What is Interoperability?

A simple definition of Interoperability is, “the ability of a system or a product to work with other systems or products, particularly in a networking environment”.

How can I educate my audio guys about AES67?

Please see the “News” section of the AES67 web-site, there are plenty of links to articles that have been written about AES67 over the past few years.

Can I use AES67 for remote contribution?

That will depend on the network connection between the remote and main site and the amount of latency it adds.  Please see, “What types of networks are supported?” in AES67 FAQ.

What intercom system systems are available for audio over IP?

EBU Tech 3347 describes a means of intercom interoperability based on EBU’s ACIP standard (see, “How does AES67 relate to the EBU’s ACIP standard?”).  Since some AES67 implementations include provisions for interoperation with ACIP, they may also be able to interoperate with intercoms built according to Tech 3347.

What’s the benefit of AES67 to me?

By buying AES67 compliant products you know that, whoever those products are made by, they will be compatible and thus you will able to stream audio between them.

If I want to use AES67 how would I do that?

You should ensure the networked audio equipment you purchase supports AES67, or will in the future.

What products support AES67?

AES67 is supported in a growing number of products from MNA members and others.  RH Consulting publish an App called “Networked Audio Devices” which lists all networked audio devices currently available.  Activating the filter for “AES67 support” lists AES67-enabled devices.  The app is currently available for iOS only and can be downloaded from the iTunes store:

I have a small home studio, what does AES67 mean to me?

If you want to expand your studio and purchase AES67 enabled products, you will have the security of knowing that the equipment will stream audio to other AES67 enabled products you may want to buy in the future.

What is the value of AES67 to a Manufacturer?

By implementing AES67 (or having an AES67 compatibility mode) you are not restricting to your networked streaming audio products working with just the streaming protocol you are using, your equipment is capable of streaming to any other AES67 product.  This allows your product to be used in a wider set of applications and environments, broadening its available market.

Are there set up guides for AES67?

In the fullness of time, the MNA hope to provide a series of documents surrounding setting up and using AES67 media networks.

Is there a Maximum Channel Count?

The maximum channel count depends on the network infrastructure.  As a general rule, a gigabit network should be able to handle 512 channels of audio at 48kHz sample rate.

Can AES67 streams be compressed to reduce the bandwidth consumed?

No, the AES67 standard specifies that all audio is uncompressed.  This is because AES67 is a high performance low latency streaming standard, compression will add latency to the system.

How do I get AES67 into my product?

Several MNA members provide OEM modules and / or services to help manufacturers implement AES67 into their products.  These include ALC NetworX, Telos, Archwave and Digigram. The solutions are summarized in this presentation:

Does the AES67 standard make it harder for manufacturers to provide unique advantages?

AES67 is a standard for audio streaming and synchronization interoperability.  AES67 was developed in recognition that new audio networking systems were using similar protocols and technology.  AES67 does not eliminate existing networking systems but allows manufactures to build bridges between systems by also implementing the AES67 interoperability mode.  Manufacturers are also able to differentiate their products based on additional unique features, increased performance and the extent to which they support optional AES67 capabilities.

What is the latency?

The AES67 standard addresses “low latency”, i.e. latencies below 10ms.  Actual latency is determined by a number of factors, such as network environmental parameters (i.e. speed, size, topology, actual traffic conditions etc.), device implementation (software and hardware), actual stream / packet setup and configured receiver latency (packet jitter compensation delay).  With a typical AES67 packet setup (i.e. 48 samples/packet, 1..8 channels, 24-bits, 48kHz) the minimum end-to-end latency which can be expected on a smaller Gigabit Ethernet network is typically 2 – 3ms (excluding any further sample processing or A/D-D/A conversion).  However, AES67 also defines other packet setups, resulting in lower or larger end-to-end latencies to accommodate various application requirements.

Does latency increase when bridging across subnets?

Minimum achievable latency with audio networking protocols including AES67 is dependent on several factors including latency through the network.  Network latency is dependent on the number of pieces of network equipment data must pass through from sender to receiver, the individual performance of this equipment and, to a lesser extent in most cases, the total length of network cabling.  Forwarding of data through network equipment may be handled at OSI layer 2 (switching) or OSI layer 3 (routing).  Routing is required for forwarding data between IP subnets.  While historically, bridging was a higher performance operation than routing, today’s multilayer switches generally deliver the same performance for bridging and routing.

Which layer is AES67 using?

Please see “What types of networks are supported?” in AES67 FAQ.

Will AES67 run over the Internet?

Please see “What types of networks are supported?” in AES67 FAQ.

Does AES67 support error correction?

No. AES67 defines linear PCM data transport (16 or 24-bit) on reliable network infrastructures which usually don’t require any error correction. However, redundancy schemes like SMPTE 2022-7 (“hitless merge”) can be added on top, but are outside the scope of AES67.

Why is there no mandatory discovery method?

The remit of AES67 was to specify a streaming and synchronization standard, not to specify a complete eco-system for streaming networked audio devices. There are a multitude of discovery methods available, each with their own strengths and weaknesses. It is hoped that one method will be adopted for all networked media devices and the industry is working towards that aim.

What control/discovery method is being recommended to pair with AES67?

AES67 does not include specific requirements for discovery and control functions. Products can use solutions of their choosing for discovery and control. Interoperability without discovery or control is ensured by mandating use of SIP for connection management and designating the SIP URI or SDP description as the information that needs to be distributed through a discovery system. Standard use of a few discovery systems including Bonjour and SAP is discussed informatively in the standard.

How do I test AES67 Switches?

Since most modern Gigabit Ethernet switches support the Quality of Service (QoS) protocols that are required by AES67, switches should not need testing specifically for AES67. AES67 uses standard Voice over IP protocols used over millions of networks daily. The key feature to look out for is support for IEEE1588-2008, which is the Precision Time Protocol (PTP) AES67 uses to keep all the devices synchronised.

Is there any AES67 conversion software (to convert from a different protocol to AES67)?

No, there is no unique software application to do this. However, you could consider the compatibility modes that, for example, Dante, Livewire and Q-Lan use when in AES67 compatibility mode as the conversion software, albeit inside the actual device as performing this task.

Is there an AES67 virtual sound card?

ALC NetworX is offering a Ravenna Virtual Sound Card for Windows which supports AES67 multicast streaming, a free version can be downloaded from the Ravenna web site (ravenna-network.com). Merging Technologies are offering a Ravenna Virtual Audio Device for OSX which also supports AES67 multicast streaming. A free version can be downloaded from the Merging Technologies web site (www.merging.com). Lawo is offering the JADE Engine, a virtual sound card for Windows supporting Ravenna and full AES67 support; JADE is commercially available with a free trial period (www.lawo.com).

If an AES67 stream is sent and no other device is subscribing to that stream, does it pass through the switch, adding traffic on the network?

AES67 supports both unicast (point-to-point) and multicast (point-to-multipoint) streaming. There is typically no network loading issue with unicast streaming. For multicast, AES67 specifies the use of the IGMP protocol for management of multicast traffic. With IGMP snooping available and properly configured on network switches, multicast traffic is only forwarded to ports where active listeners are present.

What types of networks are supported?

All protocols used by AES67 are routable over IP networks. High-performance media networks support professional quality audio (16 bit, 48 kHz and higher) with low latencies (less than 10 ms) compatible with live sound. The level of network performance required to meet these requirements is achievable on campus-scale networks but generally not on wide-area networks or the public Internet. Because IP protocols are readily carried over Ethernet networks, the standard is also fully applicable to Ethernet networks of any size.

What is the difference between AES50 and AES67?

AES50 is a professional multi-channel audio interconnection standard rather than a network. It was first published by the Audio Engineering Society in 2005. It can be considered as an alternative to AES10 (MADI) rather than as an audio network standard such as AES67. There is no specific relationship or compatibility between AES50 and AES67.

What is the difference between AES67 and AVB?

The AVB standards define improvements to the standard Ethernet layer 2 protocol to provide synchronization, Quality of Service (QoS) and an admission control behaviour that prevents the network from becoming overloaded by media traffic; an AVB network requires use of specific AVB Ethernet switches. AES67 utilizes protocols on layer 3 or above, so is able to function using standard Ethernet switches. While it is entirely possible for AES67 to function over an AVB network, AES67 will not receive any performance benefits from the capabilities of the AVB network, except if the AES67 device fully supports the AVB layer 2 protocol stack.

How does AES67 compare with AVB?

AES67 is a standard for high-performance audio over IP interoperability, fully building on IP / Layer 3 protocols and above. AVB is a set of protocols expanding Ethernet / Layer 2 capabilities to enable the time-sensitive transport of media data including video and audio. It requires all participating devices (senders, talkers and switches) to support these protocols (of which some require dedicated hardware support not available in most “legacy” gear) and is limited to operate on a single LAN (so it is not routable). AES67 can run on existing manageable network infrastructure and can also work across subnets (i.e. AES67 is routable).

How does AES67 relate to the EBU’s ACIP standard?

ACIP was part of the inspiration for the development of AES67. ACIP stands for Audio Contribution via IP and is used in radio applications by field reporters and for remote interviews to provide an interoperable means of delivering high-quality audio over distance. AES67 differs from ACIP in that AES67 includes provisions for precise synchronization using the IEEE 1588 precision time protocol. AES67 applications typically are more latency-critical than ACIP application though AES67 specifies an optional higher latency (4 ms) mode for interoperation with ACIP devices.

I’ve heard about AES67, I wanted to know about AES70?

AES67 is an AES standard, “Standard for audio applications of networks – High-performance streaming audio-over-IP interoperability”. AES70 is an separate AES standard, “Standard on audio applications of networks – Open Control Architecture” which defines a scalable control protocol architecture for professional media networks. AES70 addresses device control and monitoring only, so it does not define standards for streaming media transport. Therefore, the Open Control Architecture (OCA) is intended to cooperate with various media transport architectures, including AES67. More information can be found at the OCA Alliance web-site, http://ocaalliance.com/.

If a Dante device is sending AES67 streams, does it send these in addition to Dante streams, resulting in a doubling of data on the network?

That depends on whether there are active subscriptions to the device from other Dante devices not operating in AES67 mode, i.e. they are communicating via Dante. If all devices are connected via AES67 streams then there won’t be any Dante streams.

Can a device send AES67 streams at the same time as it sends Dante or QLAN streams?

It depends on the specific AES67 implementation but, generally, yes they can. Having this ability enables multiple protocols to function on the same network, which may be of benefit if some equipment only supports the proprietary protocol.

Do all Dante products support AES67?

Audinate has released AES67 support for the Brooklyn II module to Dante licensees. Products utilizing the Brooklyn II module will support AES67 once the product manufacturer releases product containing the required Audinate firmware, or releases an AES67 firmware update for existing products.