FEATURE ARTICLE

AES67
How the net was won
Francis Rumsey
Staff Technical Writer
The AES67 standard describes a relatively straightforward
collection of networking solutions and protocols that together
enable audio networks to interoperate. A special session presented
during the 135th Convention explained the decisions that were
made and the compromises involved during the development of the
standard, led by some of the key protagonists.

T
he AES67 standard for network audio
interoperability, launched in Septem-
ber last year, stands as a beacon of
cooperation between otherwise competing
parties. During a special session that was
part of the network audio track at the 135th
Convention, chaired by Greg Shay, some of
the leading lights explained how the stan-
dard was designed. Also included in this
article is a summary of the key features of
AES67, a standard that will change the way
that audio networks operate together.
WHAT PROBLEMS WAS AES67
DESIGNED TO SOLVE?
Andreas Hildebrand of ALC NetworX
explained that the new standard aimed to
tackle the issue of interoperability for audio
networks based on Internet Protocol (IP)
using existing solutions as much as possible.
Key criteria of the AES project, originally
known as X192, included low latency (less
than ten milliseconds) and high perform-
ance, but the scope excluded non-IP
networks, audio data compression, and low-
performance networks such as the public
Internet. Video was excluded, but the foun-
dations set out in AES67 are likely to be
useful for video as well as audio. The group
undertaking this challenging task consisted
of members from over 100 companies, as
well as broadcasters and live sound engi-
neers. Led by Kevin Gross, it managed to
move from inception to published standard
within the impressive time scale (for stan-
dards work) of three years.
Although there had been a number of
existing protocols for carrying audio based
on IP, it had not been possible until now to
exchange data packets between networks
using them. (Kevin Gross adds that when
investigating the existing proprietary solu-
tions, it was found that although they used
similar approaches they were not designed
to talk to each other, as shown in Table 1.)
These issues came down to questions
including methods of synchronization,
payload formats, and the way in which the
transport system was used.
AES67 IN A NUTSHELL
The topic of synchronization was of crucial
importance, said Hildebrand, and the group
settled on IEEE1588–2008 as the way for-
ward. This essentially specifies the Preci-
sion Time Protocol (PTP) version 2 as the
means to achieve synchronization. PTP dis-

Technology Purveyor Date intro Synchronization Transport

Ravenna ALC NetworX 2012 IEEE 1588-2008 RTP
AVB mIEEE, AVnu 2011 IEEE 1588-2008 advanced profile Ethernet,
(IEEE 802.1AS) RTP
Q-LAN QSC Audio 2009 IEEE 1588-2002 UDP
N/ACIP EBU 2007 Data packet arrival times RTP
Dante Audinate 2006 IEEE 1588-2002 UDP
Wheatnet-IP Wheatstone 2005 Proprietary RTP
LiveWire Telos/Axia 2004 Proprietary RTP

Table 1. Existing network technologies, listing their sync and transport methods (courtesy Kevin Andreas Hildebrand explained the basic
Gross) principles of AES67.

190 J. Audio Eng. Soc., Vol. 62, No. 3, 2014 March


tributes absolute time data to devices on
the network, whereas media clocks for indi-
vidual devices are generated locally from
the synchronized time data. A system mas-
ter clock is referenced to something like a
GPS-referenced time signal and can tell
slave clocks the correct time down to 25 ns
accuracy (although that level of precision is
not used in AES 67).
Transport of packets uses IP version 4,
although provision for IP version 6 has
been made for some time in the future.
The standard is based on RTP (Realtime
Transport Protocol), which itself is based
on UDP (User Datagram Protocol—a rela-
tively simple and fast method of transfer-
ring packets that does not require
handshaking) and IP. Receivers must
support both unicast and multicast modes
while senders may support unicast, multi-
cast, or both. While Layer 1 solutions
make use of the lowest layer of the OSI
network model, which is the physical
layer (e.g., copper/fiber cable), Layer 2
solutions use Ethernet protocols. Layer 3
solutions (as used by existing solutions
such as Dante and LiveWire) are based on
IP, on top of which is laid UDP and RTP.
Gross adds that using the IP layer
enables better scaling in terms of number
of participants and geographical extent
than Ethernet and is more secure and
manageable. The IEEE 802.1 AVB (Audio-
Video Bridging) standard, by the way, only
enhances the Layer 2 Ethernet solution.
This is discussed further below.
Some recommendations on sampling
rate and resolution were made, namely that
receivers should support 16- and 24-bit
linear PCM at 48 kHz, whereas senders may
support 16 bits, 24 bits or both. Although
sampling rates of 44.1 and 96 kHz are
supported, they are not mandated in
AES67. It was also decided that 1–8 channel
audio support per stream would be manda-
tory, but any number of streams could be
carried up to the bandwidth capacity of the
network. This could mean that up to
around 500 channels could be carried on a
gigabit Ethernet link. All devices should
support packets lasting 1 ms (48 samples at
48 kHz), but 4, 1, 1⁄3, 1⁄4, and 1⁄8 ms packets are
also supported
“Differentiated services” (DiffServ) has
been employed as a means of delivering
quality of service, and connection manage-
ment is based on the Session Description
Protocol. For unicast connections the
Session Initiation Protocol (SIP) is used.
Discovery of devices on the network has
been excluded from the standard for
reasons that will be described later.
J. Audio Eng. Soc., Vol. 62, No. 3, 2014 March
WHAT ARE THE MAIN
APPLICATIONS FOR AES67?
Hildebrand also outlined some of the main
intended application areas for AES67. These
include commercial audio applications such
as installed operations in stadiums, the-
aters, and theme parks, as well as fixed and
touring live sound. It is also suitable for
broadcasting houses and media production
operations, including interfacility connec-
tions. Although wide area networks (WANs)
such as the public Internet are not the main
target for AES67, special WAN services can
be employed to enable it to operate over
large corporate networks, for example, pro-
vided that various features are implemented
to ensure the performance is adequate.
HOW DO EXISTING AUDIO
NETWORK STANDARDS FIT IN?
It would seem that for existing proprietary
network technology to fit in with AES67
some form of adaptation will be required
in most cases. This seems likely to be
achievable by means of additional protocol
options for existing equipment (supplied
by means of firmware upgrades, for exam-
ple), or by using new equipment that can
handle both AES67 and proprietary flavors
of communication.
By offering AES67, a manufacturer of
audio networking equipment would essen-
tially be accepting that open standards are
the way forward, requiring them to distin-
guish themselves from the competition by
other means than the old argument of “you
have to buy all your equipment from us if
you want it to work together.” It is still
possible, of course, that operating certain
equipment in proprietary modes may offer
selected advantages in terms of perform-
ance or features, but this would become a
user choice.
Manufacturers of proprietary networking
solutions are currently at various stages in
their attitudes to AES67. The RAVENNA
audio networking protocol, for example, is
already essentially AES67 compatible, said
Hildebrand. New nodes being manufactured
by Axia for LiveWire will also be fully
AES67 compatible, although legacy nodes
will not. A bridge is possible that will enable
older nodes to talk to AES67 networks.
AES67 streams are compatible with EBU
ACIP (Audio Contribution over IP) systems,
although ACIP does not incorporate
absolute time in the synchronization
stream so it would not be fully AES67
compatible. The facilitation of 192-sample
packets in AES67, for example, was specifi-
cally included to enable stream compatibil-
ity with ACIP devices.
FEATURE ARTICLE
Gints Linis explains the thinking behind the
decisions
An AVB node is essentially a Layer 2
network solution, so such a thing by itself
cannot support AES67. However it is possi-
ble to run AES67 across an AVB network,
and AVB devices use a variant of IEEE1588
synchronization, so much of the key tech-
nology is already present. For AVB devices
to fully support AES67, though, they would
have to incorporate the IP-based means of
data transport. There is a chance, therefore,
that AVB-biased manufacturers will also
adopt AES67, suggested Andreas.
MAKING THE DECISIONS
Gints Linis explained some of the thinking
behind decisions made during the forma-
tion of the standard. There were three main
conflicting factors—the technical ideal, the
costs of implementation, and solutions that
already exist.
Header extensions are not recommended
in AES67, for example, said Linis. They are
often poorly implemented, poorly tested, or
simply do not work, but receivers must be
able to tolerate whatever comes in without
crashing. The 44.1 kHz sampling rate was
not made mandatory in the standard
because it is often considered a consumer
rate and seems likely to disappear eventu-
ally. 96 kHz was not made mandatory to
avoid placing a needless burden on devices,
although it is optional.
A packet duration of 1 ms is not compati-
ble directly with any of the technologies
whose developers participated in the creation
of this standard, so it might be asked why it
was decided to use it for AES67. Although
not perfect, Linis explained that such a
packet size is sufficiently short for buffering,
and the packet rate is low enough not to
overload the CPUs of some devices. If you
191
FEATURE ARTICLE
CHANNEL BUNDLING
The standard discusses the bundling of
related channels in the following way:
“Although bundling multiple channels in
a stream can improve network and pro-
cessing efficiency, it is recommended
that bundling be used primarily in serv-
ice of the application. Channels of
related material (for example, stereo or
surround sound) are good candidates
for bundling. Bundling of unrelated
channels destined for different receivers
in an effort to reduce network overhead
is discouraged as this complicates
media routing configuration.”
want compatibility “out of the box,” he said,
this is what you get here. A longer packet of
4 ms is allowed for compatibility with ACIP
devices, but this is not mandatory. It is a
common trend for devices to become more
flexible, so it seemed likely that a variety of
packet sizes would be possible in future, and
there is also a trend towards lower latency.
Shorter buffering offers lower latency but
might cause dropouts, whereas longer buffer-
ing improves robustness but could impose
more constraints on the implementation. A
compromise needed to be achieved between
options that could be implemented in a range
of devices.
THAT SYNCING FEELING
Stefan Heinzmann delved more deeply into
matters of synchronization in AES67.
Among the main requirements had been to
have phase accuracy between multiple inde-
pendent nodes on a network, whether they
were receiving the same stream as each
other or not. This was partly to ensure
things like accurate stereo imaging, which
demands close coherence between audio
channels. A separate clock signal (on a sep-
Stefan Heinzmann deals with the ins and outs
of synchronization.
192
arate connector) was regarded as undesir-
able, so it was important that sync should
be a feature of the network protocol itself.
Furthermore it was desired to be able to
distribute several media clocks simultane-
ously on the same network, to allow for a
range of audio and video systems and
devices to be operated at different rates.
Another requirement was to be able to run
on standard network infrastructure, say
using existing routers and switches, as we
can’t require IT infrastructure to be
entirely replaced in order to handle audio.
The house clock requirement could be diffi-
cult to fulfil in this case, but basic stream-
ing should be possible regardless of legacy
equipment.
The existing AES11 standard has rules
for synchronizing different pieces of
equipment in a larger system, and this
suggests that devices need to be locked to
within 1 µs. A protocol needed to be
adopted for AES67 that could assist in this
process, one that was likely to work across
a whole range of existing IT devices. There
was only really one option, and that was
PTP. However there are several variants of
PTP that are mutually incompatible, so the
group settled for version 2 (2008) that had
some useful features such as profiles
(designed for different applications). PTP
can run on Layer 2 Ethernet, IPv4, or
IPv6, so the group settled on IP version 4.
PTP, it must be realized, distributes
absolute time data, not a clock signal, so
individual nodes have to generate their
own clock signals from the time data.
There is explicit information in the stan-
dard about how to generate sync clocks
from the time data, so that this is not left
to chance. Also, even though the standard
does not deal directly with audio/video
sync issues such as drop-frame timecode
rates, there is provision to be able to
handle such scenarios in the implementa-
tion. Liaison with SMPTE, which is devel-
oping a related networking standard,
principally for picture streams, is helping
to iron out these matters so that the two
standards are compatible.
Although network switches do not tech-
nically need to be “PTP-aware” to handle
synchronization data, some switches do not
support PTP to the required level of accu-
racy. So if one wanted to use AES67 to
distribute a house clock accurately it would
be necessary to upgrade switches to those
that could handle PTP natively. This is one
of the compromises in the standard—an
area in which legacy network equipment
might not be able to handle all of the new
requirements.
AES67 AND OTHER NETWORK
TECHNOLOGY
Kevin Gross pointed out that it had never
been the aim to create more confusion in the
market by creating another competing stan-
dard. The existing approaches were all essen-
tially trying to achieve the same thing, so it
had been important to attempt compatibility
with the best parts of those, rather than
introduce a lot of new concepts. Putting
together pieces of technology that already
exist seemed like a much more likely
approach to succeed than “making stuff up.”
However AES67 was never intended to solve
everybody’s problem, it was aimed at a spe-
cific market that needs high-performance
audio with low latency and was not going to
be particularly useful for, say, speech codecs,
and would not work on all networks.
AVB was one particular IEEE standard
that Kevin wanted to contrast with AES67,
as there can easily be misunderstandings.
Both standards use IEEE1588 sync
arrangements for example, but the main
difference with AES67 is that it allows you
to use a standard IP network if you wish.
This gives rise to a lower sync accuracy but
it’s still reasonably useful, whereas AVB
enables one to get very precise timing
accuracy under all circumstances. It does,
however, mean that you have to use AVB-
compliant switches, which could be
regarded as a barrier to interoperability.
AVB uses an alternative BMA (best master
clock algorithm) to that defined in the
basic IEEE1588 standard (the version
adopted for AES67), to choose the most
appropriate sync source on the network
automatically. This can mean that it takes
perhaps half a second longer to set up the
master clock source on an AES67 system,
Kevin Gross said,”We tried to avoid creating
more confusion by creating another standard.”
J. Audio Eng. Soc., Vol. 62, No. 3, 2014 March

but it is likely to work with a broader range
of equipment. (Annex D of the standard
explains how to use the highly accurate
clocking system employed in AVB as a
replacement for that specified in AES67.)
AVB uses Ethernet as a transport proto-
col and employs a VLAN tag at the start of
each packet to set a high priority. Within
these AVB packets the audio information is
carried as a Firewire payload. So essen-
tially AVB is a form of “Firewire over
Ethernet.” AES67 uses the 6-bit DSCP
field in the IP header for setting packet
priority. (VLAN tags are allowed but are
not required for AES67.) Kevin explained
that the majority of IT professionals know
a lot more about IP than they do about
lower-level Ethernet, so this was an argu-
ment to go with IP for AES67.
There is a bandwidth reservation
approach used in AVB that attempts to
calculate whether there is sufficient band-
width to handle a stream on the network
before it is “admitted.” This is designed to
ensure that if a stream is allowed onto the
network it will always have enough capacity
to run properly. AES67, on the other hand,
does not employ any such “admission
control,” so if there is insufficient capacity
you will experience unreliable transmis-
sion. It’s therefore up to the system
designer to make sure that the network has
sufficient capacity to handle the scenarios
you expect. (This is also true of AVB, of
course, it’s just that with AVB you would
get an “access refused” response if you tried
to send data on a network that was already
too full, rather than it being accepted and
the result being unpredictable.) There have
already been some failed attempts by the
Internet Engineering Task Force (IETF) to
introduce forms of admission control for
IP-based networks, and those people have
pretty much given up on the idea, said
The AES67 project group celebrates the successful completion of its work, with Richard Foss (chair, working group SC-02-12) and Kevin Gross
(leader of the project) seated center.
J. Audio Eng. Soc., Vol. 62, No. 3, 2014 March
Greg Shay spoke on management and
discovery.
Gross. If you want such a feature, you
always have the choice of using an AVB
network, or indeed running AES67 data
over an AVB network, as described in Annex
C of the standard.
CONNECTION MANAGEMENT
AND DISCOVERY
Connection management is about getting
audio communication going, said Greg
Shay, whereas discovery is about finding
out what devices are on the network, rather
like a phone book. In AES67 there is no
connection management on top of the mul-
ticast mode. In essence, audio streams are
broadcast on the network and other devices
pick them off as required. This is very sim-
ple to implement. Internet Group Manage-
ment Protocol (IGMP) is usually imple-
mented in a network switch and it simply
requires that devices advertise themselves
as potential sources, while receivers sub-
scribe to a particular multicast stream.
AES67 needed to have a unicast mode as
well as multicast. Unicast modes involve
point-to-point connections between
FEATURE ARTICLE
devices. (Kevin Gross comments that
unicast is more secure and can be more
simple and efficient if there is only one
intended receiver.) SIP (session initiation
protocol) can be used to set this up, being a
protocol that is also used for things such as
establishing telephone calls over IP. It
involves a certain software overhead but it
was considered “worth it,” said Shay.
Dealing with the “discovery problem”
was one of the biggest compromises that
the group made, according to Shay. With
many audio channels available, an auto-
matic system to find what is “out there”
would have many advantages. However
there was no off-the-shelf solution that
would do everything for everyone, and the
group did not want to compromise the
future use of the standard by saddling it
with a solution that was inadequate for
some use cases. An appendix to the stan-
dard, therefore, presents a survey of exist-
ing options, leaving it to the user to
implement whatever is appropriate.
SUMMARY
The AES67 standard describes a relatively
straightforward collection of networking
solutions and protocols that together
enable audio networks to interoperate. This
may require some existing systems to be
adapted, and the approach may not work
under all circumstances or for all applica-
tions, but the building blocks are those
used in standard IP network systems and so
should be relatively easy to implement by
developers.
Editor’s note: Go to
www.mobiltape.com/conference/Audio-
Engineering-Society-135th-Convention to
purchase and download an mp3 (13AES-
N05) of this workshop.
193