Audio Engineering Society

Convention e-Brief 241

Presented at the 140th Convention
2016 June 4–7, Paris, France
This Engineering Brief was selected on the basis of a submitted synopsis. The author is solely responsible for its presentation,
and the AES takes no responsibility for the contents. All rights reserved. Reproduction of this paper, or any portion thereof, is
not permitted without direct permission from the Audio Engineering Society.

Setting Up and Making an AES67 Network Coexist with

Standard Network Traffic
Mickaël Henry1, 3 , Lucas Rémond2 , and Nicolas Sturmel3
1 UVHC, Valenciennes, France
2 CNSMDP, Paris, France
3 DIGIGRAM S.A., Montbonnot, France

Correspondence should be addressed to Nicolas Sturmel (sturmel@digigram.com)

ABSTRACT
In this paper we will show how an AES67 network can coexist within a standard non-audio network. We will detail
the difficulties usually encountered when setting up and using AES67 networks. We will analyse the utility of the
network protocols required by AES67: (i) IGMP and its impact on devices features, (ii) PTP and the clock recovery
performance when using PTP-enabled switches and (iii) QoS and the impact of non-audio traffic such as web and
corporate traffic. We will use a set-up of ten different AES67 compliant devices from many manufacturers and
supporting various AoIP protocols all compliant to AES67. We will provide recommendations in order to provide
proper quality of experience while making networks coexist.

1 Introduction the network be managed with care, but best practices

Audio over IP (AoIP) protocols [1] allow audio real
time exchange of audio data on a local area network.
However, devices from different manufacturers use dif-
ferent protocols. The AES67 [2] standard was proposed
by the Audio Engineering Society to facilitate the inter-
operability between them. Nowadays, one often uses
two physical networks to separate AES67 streams from
non-audio traffic. With this setup, disruptions risks are
limited, but switching to AoIP requires the installation
of a dedicated infrastructure for the audio network. The
perspective of using one network only would facilitate
AoIP transition. However, using an existing network
for real time audio may lead to audio glitches: the
non-audio traffic (web, corporate traffic, ...) may cause
packet losses or bad clock synchronisation between
audio devices. To avoid this caveat, not only should
and limitations have also to be considered. The AES67
standard has a list of recommended best practices to
this extent. The goal of this paper is to analyse those
recommendations and show how it is possible to make
coexist non-audio and AES67 on the same network
with the best rate and without disruptions.
AES67 is based on several protocols: IGMP (Internet
Group Management Protocol) [3] which regulates and
manages multicast subscription for each equipment;
PTP (Precision Time Protocol) [4] that allows fine syn-
chronisation between devices by distributing time on
the network, and QoS (Quality of Service) [5] which
manages packet prioritisation based on a specific field
in the IP header. However, optimal synchronisation
using PTP is achieved by using specific switches that
support the protocol and correct the jitter on packet
delivery. AES67 recommends the use of the PTP me-
Henry, Rémond, and Sturmel AES67 and Standard Network Coexistence

dia profile (Annex A of [2]) : higher clock distribution

frequency.

A real-time audio network over IP is typically using

full duplexGigabit Ethernet (GbE) links. So how many
audio channels or streams is it possible to transport
over one single link? The following formula allows
to calculate the bitrate per audio channel in an AES67
network:
n.t. f .r + 8(70 + IPG)
D=
1000.n.t
Where D is the bitrate per channel in Mbps, n is the
number of channel(s) per stream, t is the packet time
in ms, f is the sampling frequency in kHz, r is the
sample resolution in bits, IPG is the interpacket gap
in bytes and 70 is the headers size: RTP header, UDP
header, IPv4 header, Ethernet header and the frame
check sequence. The standard minimum interpacket
gap at emission is 12 bytes.
The paper is organised as follows: in Section 2 a local
area network will be set up to simulate a network and
results will be presented. In Section 3, a configuration
will be chosen to confirm whether or not both networks
can coexist. Finally, best practices to limit disruptions
will be given in the conclusion.
2 First experiment
2.1 Setup
Firstly, Figure 1 presents the experimental setup com-
posed of two computers for TCP/web traffic and more
than 10 AES67 compliant devices that exchanged audio
streams on the network. With two switches, we were
able to create an observable trunk link where both non-
audio and audio traffic were guaranteed to go through.
Those switches offered 1 Gbps ports, supported PTP
BC mode and were able to handle packet priority thanks
to 8 priorities queues. Devices were exchanging audio
streams according to the AES67 standard at a sampling
frequency of 48kHz.
Secondly, the traffic was separated in two ways: - Non-
audio traffic which was composed of several file trans-
fers, and general IT services (discovery and domain
name services). In order to simulate heavy traffic we
installed FTP servers on each computer to perform file
transfers. The file size was 7GB; - Audio streams were
Fig. 1: Setup
created with several devices. Each stream was com-
posed of 60 channels, 8 samples per channel (1/6 ms
packet time) ; we doubled the number of sources after
each conditions. Note that in order to have the highest
bandwidth we chose stream configurations that are not
fully AES67. Regarding the different protocols, IGMP
and BC were switched on and off with both PTP pro-
files. QoS, which links AES67 packets (clock, audio
and management page) with priority level offered by
switches, was also switched on and off.
Finally, the clock jitter and the audio jitter were mea-
sured. We define jitter as the maximum excursion of a
given value from a reference. In the case of the audio
clock, jitter would be the maximum offset between the
reference clock and the synchronised client. The first
was measured with an oscilloscope, while the second
was measured with the help of the management web
page of devices. We limited the non-audio bandwidth
at around 350 Mbps. The bitrate per channel was 1.214
Mbps on a GbE link, meaning that we could afford up
to 823 audio channels maximum. However, we limited
to 600 channels in order to preserve bandwidth for non-
audio traffic. Table 1 represents a summary of all the
conditions for this experiment.
Protocol Conditions Tested
IGMP With and without
PTP With and without support
QoS With (following AES67 reco.) and without
PTP Profiles Default or Media
Table 1: Summary of Conditions tested
2.2 IGMP
When IGMP protocol was disabled, devices with a
bandwidth of 100 Mbps were not reachable on their

AES 140th Convention, Paris, France, 2016 June 4–7

Page 2 of 4
Henry, Rémond, and Sturmel
Fig. 2: Evolution of clock jitter over the number of channels
web pages if audio streams were present on the network.
Thus, the use of IGMP was necessary
2.3 Clock Recovery Precision
It is important to note that with PTP, each device is
responsible for the quality of the clock recovery based
on the jitter induced on the network. Therefore, mea-
suring clock precision is a way of assessing the effect
of non-AES67 traffic on PTP. We began by setting a
threshold above which the clock was considered to be
“off”. We chose the value of 11 µs because it represents
half a sample at 48kHz. With such a threshold we were
trying to validate clock accuracy around 1 sample. In
our experiments, we noticed close results between the
default and media PTP profiles, therefore we will only
present and discuss the results of the default profile.
Figure 2.A shows the evolution of the clock jitter when
the number of channels on the network increases, with
audio traffic only and without QoS. We see that above
120 channels, clock recovery can only be satisfactory
performed with the BC mode. When non-audio traffic
was moving on the same network (Fig. 2.B), values of
clock jitter increased with the number of channels to the
point of total clock instability (clock off by more than
60 µs) without PTP support. Overall, it is not achiev-
able to have a satisfactory AES67 setup in the presence
of non-audio traffic without BC or QoS support.
AES 140th Convention, Paris, France, 2016 June 4–7
Page 3 of 4
AES67 and Standard Network Coexistence
On Figure 2.C, we activated QoS with audio traffic only
on the network. In this case, the efficiency of the QoS
was insignificant. If we compare Figure 2.C with Fig-
ure 2.A, we do not see any big difference between the
curves. However, on Figure 2.D, when non-audio traf-
fic was present, QoS revealed all its efficiency: above
240 channels (291 Mbps), we see that the "OFF" curve
stays close to the threshold.
This sub-section showed the efficiency of the BC mode:
it allows to have the lower clock jitter which otherwise
would be above to the 11µs threshold. Notice that mea-
sured jitter is consistent with basic principle of QoS:
indeed if a big frame (close to the MTU of 1500 bytes)
has begun transmitting on the link, the PTP packet with
highest priority might be stalled for (8*1500 / 1 000
000 000) seconds = 12 µs, plus the interpacket gap time,
a number close the measured jitter.
2.4 Audio Jitter and overall bandwidth
The evolution of audio jitter - with and without non-
audio traffic, with and without QoS - is shown on Figure
3. We can see that the audio jitter increases significantly
in the worst conditions, without QoS and with a large
number of channels. However, if the number of chan-
nels is less than 120, then non-audio traffic and QoS do
not seem to have any impact on the audio jitter.
Figure 4 shows the download speed between two com-
puters which were connected on the network. Without
Henry, Rémond, and Sturmel
Fig. 3: Evolution of audio jitter
QoS, the rate speed decreased slowly from 240 chan-
nels (291 Mbps) and fastly from 480 channels (582
Mbps). When QoS was activated it started to kick in
from 240 channels. The non-audio traffic speed rate
kept at a slowly decrease.
Fig. 4: Evolution of IT speed rate
3 Validating network
Starting from previous results, we chose the following
setup to make a long term test and validate it. We
limited the number of channels at 120 in both ways,
we decided to switch IGMP on, selected the BC PTP
mode and we chose to activate QoS. On this new setup,
a digital audio integrity test was assessed in order to
see the reliability of the audio transfer. After 24 hours,
no audio loss was observed. The clock jitter was low
(2.4 µs), far below the threshold (11 µs). Concerning
the audio jitter, it remained at a constant value of 192 µs.
The non-audio speed rate stayed identical to 350 Mbps
and 2.54 TB transited on the network.
4 Conclusion
Making an AES67 and an non-audio network coexist
can be a difficult task. According to the use of each
AES 140th Convention, Paris, France, 2016 June 4–7
Page 4 of 4
AES67 and Standard Network Coexistence
network and to their respective allocated bandwidth,
disruptions can come out such as bad audio clock or
packet losses. Different network protocols, IGMP, PTP
and QoS proved their efficiency to minimise disruptions
that may appear.
To sum up, an effective way to configure both networks
is first to use IGMP protocol for a high number of
streams, at least not to overload 100Mbps devices that
are necessary according to the setup. Then, BC PTP
mode on switches, if available, should be used to min-
imise the clock jitter. However, it is not an imperative
need to have any PTP-enabled switches in a setup, pro-
vided it is AoIP dedicated and relatively small (less
than 60 audio channels). Furthermore, QoS should be
activated to limit disruptions. Lastly, we successfully
tested the network with 120 channels and 350Mbps
of non constant non audio, to be sure that we avoided
audio glitches.
References
[1] Bouillot, N. and et al, “AES White Paper : Best
Practices in Network Audio,” Journal of Audio
Engineering Society, 57(9), pp. 729–741, 2009.
[2] AES, “AES standard for audio applications of net-
works - High-performance streaming audio-over-IP
interoperability,” 2013.
[3] Fenner, W., “Internet Group Management Protocol,
Version 2,” RFC 2236 (Proposed Standard), 1997,
updated by RFC 3376.
[4] IEEE, “1588-2008: IEEE Standard for a Precision
Clock Synchronization Protocol for Networked
Measurement and Control Systems,” 2008.
[5] Nichols, K., Blake, S., Baker, F., and Black, D.,
“Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers,” RFC 2474
(Proposed Standard), 1998, updated by RFCs 3168,
3260.