new standard recently approved by the Audio Engineering Society
should guide the development of audio over Internet protocol for the
professional and broadcast industries. Published on Sept. 11, 2013,
AES67-2013 is the outcome of more than two years of work by a large
group of participating companies, some of them in the broadcast
industry, with an interest in IP audio.
visited this topic in the Oct. 17, 2012, issue of Engineering Extra
with an extended interview with Kevin Gross, leader of the AES-X192 standards development committee that led to
AES67. He said then that a new standard would allow audio equipment
from various manufacturers to interoperate without requiring an
external between-type translator. The hope is that, in turn, this
will allow the IP audio industry to grow more quickly and
going further, it might be helpful to talk a bit about the
technologies involved and how we got to where we are today.
and foremost, it is essential to recall that when it comes to all
things Internet-related, there is a standards body, known as the IETF
or Internet Engineering Task Force. This somewhat amorphous and
independent group is the source of what are known as “Request for
Comments” documents, or RFCs. The IETF operates under an
organization known as the Internet Society, having morphed from what
was initially a United States government agency into an independent
IETF defines the standards that are used in IP by issuing RFCs on
various topics. Most of us know that the Internet is a system of data
communications developed by a government agency, DARPA, whose initial
purpose was to be self-healing in case of war or civil disruption. It
relies on packets of data with a simple address scheme that allows
packets to be routed to their destination based on changing network
the implications of the Internet’s power and simplicity became more
understood, and network speeds began to grow, network engineers began
to think of ways to use it for more than just transferring data files
comprised of text. To ensure these other forms of transmissions would
be compatible, sets of standards were developed to cover as many
types of communications as could be imagined. These sets of standards
were defined and refined by issuance of RFCs to cover every topic.
example, the idea of transporting audio and video by Internet as a
real-time process was developed in 1996 under RFC 1889, which was
then superseded by RFC 3550 in 2003.
is important to distinguish audio and video as “real-time”
processes, as opposed to a file transfer that can be played back
after a complete file has been received.
be useful in a broadcast system, audio must mimic real time — the
delay between when audio leaves a source and ends up in our ears via
a set of speakers must be small enough to be unnoticeable. However,
due to the need to break up an audio signal into packets, encapsulate
them, transport them, re-order them in time and then reassemble the
original signal, by definition transporting audio by IP can’t be a
real-time process. The difference between real time and the actual
delivery time is a delay known as latency.
an audio standard to be called high performance, it is essential to
standardize on a maximum latency for audio transport that meets the
goal of being unnoticeable. This is a special case of data
transmission that requires its own set of rules and procedures.
a certain packet size and definition of address header content must
be maintained to optimize audio performance.
definitions and concepts are encompassed in the development of a pair
of standards known as Real-time Transport Protocol and Real-time
Transmission Control Protocol, or RTP and RTCP. These standards are
at the heart of Internet audio, from high-speed LAN based systems to
streaming audio over the public Internet.
the United States, the radio broadcasting industry has already shown
itself ready, if not advanced, in the move to embrace networked audio
initial driver was the development of cheap and accessible switches
designed for computer networks that could transport more than enough
bandwidth to handle digital audio successfully over inexpensive
Category 5 wiring. Early systems, known as Layer 2 type, used the
Ethernet protocol to connect between machines using what is known as
the MAC address, a unique device identifier.
was an interesting and valuable transport, but it did not connect
audio across anything but a flat switch environment. Networked audio
requires the use of IP addresses. As Layer 3 switches capable of
decoding packet IP addresses came to market and dropped in cost,
manufacturers moved to implement true audio networks.
and Axia are among those in the United States that have developed and
marketed IP audio systems. In Europe, a number of companies have come
up with similar systems, such as Ravenna from ALC NetworX. While all
these systems feature audio that can be transported over networks
using standard protocols defined as above, the fact that they were
developed independently results in the unsurprising outcome they
don’t necessarily work with each other.
attempts to resolve that problem by defining a standard approach to
using these already standardized protocols. Essentially, it defines a
way of using the standard protocols, such as RTP, in a manner that is
the same for everyone.
great benefit to the audio community of developing an IP audio
standard is that it opens up a consistent method of routing
high-fidelity audio signals over any and all IP networks. Previous
efforts resulted in proprietary methods that would work within the
confines of a high speed LAN, possibly with custom configurations in
network switches, or even custom featured network switches as
proposed by AVB. AES67 allows what have been, up until now, islands
of audio networking to connect directly to the public Internet and in
turn transport packets into what had been foreign networks.
IT END HERE?
is this the final word on IP audio standardization?
Owens, who handles eastern U.S. sales at Wheatstone Corp., said,
“Definitely not.” He describes AES67 as “a basic framework that
allows manufacturers to use the same base parameters needed to send
and receive multicast audio over IP between their I/O devices.”
Hildebrand of ALC NetworX agrees: “It is neither intended to be a
complete solution on its own nor will it replace existing solutions.
… As such, the standard defines a minimum set of protocols and
formats which need to be supported by other solutions in order to
establish synchronization and stream interchange.”
made the point there is much more to a professional IP audio system
than just the transport standards.
the elements of discovery or control … AES67 only provides raw
audio transport,” Owens said. This means that how an individual
manufacturer might implement start/stop functions on a console or
studio tally lights is still likely to remain proprietary.
adds, “Existing solutions usually offer functionality or
performance characteristics which go beyond AES67 (e.g. advertisement
and discovery, device control, lower latency, extended payload
formats, higher sampling rates etc.); consequently AES67 intends not
replace these solutions, but requires manufacturers or solution
providers to enhance their capabilities to support AES67 guidelines.”
had this to say about the possibility of future standards efforts:
“Proprietary systems will always have a functional advantage —
devices that are designed from the ground up to work together as a
system will do just that with no translation required. This includes
interfacing with third-party devices using the standards-based
manufacturers’ protocols currently available. We do expect, though,
that there will be future specs developed that can be used in
conjunction with AES67.
is an example. This spec proposes to standardize control elements by
assigning every possible control a number, much the same as MIDI
controllers work in the world of musical instruments. For example, a
sustain pedal ON message #64 is understood by all synth
manufacturers. Over time, AES67 and other associated specs may
provide all the functions needed for true interoperability.”
live in a world that is moving quickly toward integrating new
products and services across networks that span all pre-existing
technologies. It’s an exciting time for audio. In 10 years, it is
likely that virtually all new equipment will be networkable and
capable of greater performance precisely for this reason.
Professional audio is moving in this direction fast. The wise
engineer will want to learn as much as possible about networking and
IP standards such as RTP in order to be able to keep up.
to Phil Owens (www.wheatstone.com)
and Andreas Hildebrand (www.ravenna.alcnetworx.com)
for their assistance.
a copy of AES67-2013 here.