370 TI 370

Media Integrated
Local Area Networking
(Milan™)
1.1 en
Notes on document version
Version 1.1:
Initial edition.

General information
TI 370 Media Integrated
Local Area Networking (Milan™)
Version: 1.1 en, 04/2024, D5370.EN .01
Copyright © 2024 by d&b audiotechnik GmbH & Co. KG; all
rights reserved.
d&b audiotechnik GmbH & Co. KG
Eugen-Adolff-Str. 134, D-71522 Backnang, Germany
T +49-7191-9669-0, F +49-7191-95 00 00
docadmin@dbaudio.com, www.dbaudio.com
Contents
Contents

1 Milan...................................................................................... 4
1.1 History...................................................................................... 4
2 Relevant technical background.................................. 5
2.1 Preliminary remark................................................................... 5
2.2 How real-time media transfer is achieved in Ethernet
networks................................................................................... 5
2.3 Challenges in converged networks........................................ 6
2.4 Technical improvements of TSN............................................. 7
2.5 TSN Profiles.............................................................................. 8
3 Specifics of AVB and Milan........................................... 9
3.1 Stream-based media transport, Dynamic Mapping, and
patching................................................................................... 9
3.2 gPTP and Media Clock Domains......................................... 10
3.3 Latency................................................................................... 10
3.4 Endstation naming................................................................. 11
3.5 Interoperability definitions of Milan..................................... 11
4 Best practices................................................................... 12
4.1 How to set up a Milan-based system................................... 12
5 Hive controller quick start guide............................. 13
5.1 Overview over the most important controls......................... 13
5.2 Basic configuration and use................................................. 14
6 Glossary............................................................................. 17

TI 370 Media Integrated

Local Area Networking (Milan™), 1.1 en 3
1 Milan
Milan

Media Integrated Local Area Network (Milan) is a network 1.1 History

protocol for real-time media that has been defined by the Avnu, a Due to being based on open standards that developed over time,
consortium of manufacturers mainly from the pro audio, network the terminology used is not always consistent. Therefore, it makes
technology and electronics industries. It is based on Time-Sensitive sense to look at a timeline that relates the overall evolution of
Networking (TSN) which is a collection of Institute of Electrical and Ethernet, the specific work of the respective IEEE working groups
Electronics Engineers (IEEE) standards that make Ethernet regarding the subject of this document and the work of the Avnu to
deterministic by default. This targets Milan at applications that each other.
must deliver precise synchronization and low latency in large,
converged networks, even when operated at high load, which is 1983 The IEEE standardizes a set of wired computer
why d&b audiotechnik sees it as the network backbone for our networking technologies under the name "Ethernet".
systems. Initially, data could be transferred over a coax cable at
10 Mbit/s.
Milan is not a proprietary product. Rather, manufacturers are free
to implement it on a variety of hardware platforms as required. At 1991 The IEEE standardizes 10BASE-T Ethernet, which first
the same time, a stringent standardization and certification process uses twisted pair cables with a data rate of 10 Mbit/s.
ensures interoperability of Milan certified devices.
1995 The IEEE standardizes 100BASE-T or Fast Ethernet with
a data rate of 100 Mbit/s over twisted pair cables.
1999 The IEEE standardizes 1000BASE-T Gigabit Ethernet
with a data rate of 1 Gbit/s over twisted-pair cables.
2004 Within the IEEE, the "Residential Ethernet" study group is
formed, later to become the Audio-Video Bridging
(Milan) Task Group.
2009 The Avnu Alliance is founded as an industry consortium
to develop open interoperability standards and
certifications and commercialize the technology.
2011 The IEEE’s AVB Task group publishes a set of technical
standards that serve to provide time-synchronization, low
latency, and reliability for real-time media transfer over
switched networks under the common name "AVB".
2012 The Milan Task Group is renamed to TSN Task Group to
reflect the much wider scope of not just ProAV, but many
other industry’s applications that time-synchronized, low-
latency data transmission addresses. Based on TSN,
several profiles are defined that address the special
needs of these various industries.
AVB is the profile for the ProAV industry.
2018 The Avnu publishes the Milan protocol, which is based
on the AVB profile of TSN. Milan declares a specific
implementation of several IEEE standards to ensure
interoperability of devices from different manufacturers.
Milan conformity is verified by a stringent certification
process that devices must pass to carry the Milan logo.

TI 370 Media Integrated

4 Local Area Networking (Milan™), 1.1 en
2 Relevant technical background
Relevant technical background

2.1 Preliminary remark 2.2 How real-time media transfer is achieved in

This chapter employs simplifications where deemed meaningful. Ethernet networks
The goal is to explain principles and their differences at a level of As initially developed, Ethernet fulfilled the goal of networking
detail that is appropriate for the scope of this document and a computers together in establishing a common standard for the
normal, interested user who is not a network expert. transfer of packet-oriented data between devices. Together with
higher-layer protocols such as TCP, the design focus was on
For further reading, an up-to-date list of applicable IEEE standards establishing a connection and ensuring that data packets reach
can be found in the latest revision of the Milan specification which their destination. Attributes such as latency or synchronization
can be downloaded from the Avnu website: were not part of these design goals.
https://avnu.org/resource/milan-specification/
With the widespread proliferation of network technology in all
Also, due to changes in terminology to make technical terms more fields private and commercial and with Ethernet evolving towards
inclusive, multiple variations of the same term may exist, much higher bandwidths toward the end of the 1990s came the
depending on when documentation was released and/or desire to transmit uncompressed, real-time audio and video
standards were last updated in this regard. This should be noted content. Here, deterministic, low latency and precise
because it may cause confusion when comparing different synchronization are crucial.
documents about the same subject matter. As a prominent
example, the long-established hierarchical and universal To this end, additional standards have been developed around the
terminology of "master/slave" is increasingly replaced by other turn of the millennium to leverage, when implemented, hardware
terms, which can differ depending on the context ("leader/ that is already widely in use. They have enabled several (semi-)
follower", "transmitter/receiver", and others). proprietary Audio over Ethernet and Audio over IP solutions such
as CobraNet, EtherSound, Dante, AES67 or Ravenna that were or
still are commercially highly successful for this reason.
Latency management by forced preferential
forwarding
To achieve low latency, preferential forwarding of specific packets
is forced by implementing Quality of Service (QoS) techniques
that introduce classifiers at the packet level (DiffServ,
"Differentiated Services"). These can be read and used by so-
equipped network switches to apply a class-specific forwarding
rule, buffering all lower-priority traffic (e.g., a print job or non-
critical control data) until concurrent higher-priority traffic (e.g.,
synchronization data, media data) has passed. This method is
referred to as Strict Priority scheduling.
The illustration below shows how a Strict Priority scheduler in a
switch handles incoming traffic of different classes. Packets
ingressing the switch through different ports and which are
forwarded from one outgoing port are processed according to
their time of ingress and priority. In the example, traffic of lower
priority is held back significantly to let packets of higher priority
pass first, even though both ingress the switch at the same time.
The result is a continuous outbound stream of packets, sorted by
class.
schematic drawing
Strict
time-critical
Priority
less critical
1st
legacy 2nd
3rd

incoming traffic outgoing traffic

Synchronization via PTPv1

Synchronization is achieved by implementing the Precision Time
Protocol (PTP). It has been published in different versions, the first
of which (PTPv1) has been released in 2002. A prominent
protocol to use PTPv1 is Dante.
The overarching principle is always identical: One network device,
in case of PTPv1 an endstation (a network device with audio I/O),
must provide a common time reference for all others to
synchronize to. This endstation is usually elected by an automated
process and is called the Leader Clock.

TI 370 Media Integrated

Local Area Networking (Milan™), 1.1 en 5
 Relevant technical background

The Leader Clock periodically sends out Sync messages that 2.3 Challenges in converged networks
contain its current time of day. All other endstations, the Followers, The schemes described in the previous section perform well in
compare the time stamp of incoming Sync messages to their own networks that
clock to determine a conversion formula that translates Leader 1. transport only one dominant kind of traffic.
Clock time to Follower Clock time: 2. have an abundance of free bandwidth.
"When I received the Leader Clock’s Sync message, it read In many systems, these conditions are easily met. For historic
10:00:00 h. At this moment, my own clock reads 09:59:00 h. reasons alone, different departments (audio, video, lighting, etc.)
So, I need to subtract 00:01:00 h from incoming time stamps tend to run separate physical networks. Also, and in many typical
in Leader Clock time to get the corresponding time of day on applications, only a fraction of the bandwidth of a Gigabit
my clock." Ethernet link is used, and higher bandwidths for inter-switch links
are increasingly commonplace.
Additionally, every Follower needs to determine the propagation
time or path delay of Sync messages through the network to offset Example:
its conversion formula accordingly. To this end, all Followers 128 channels of 96 kHz/24-bit audio require less than
periodically send Delay Request messages to the Leader Clock 400 Mbit/s of bandwidth or less than 40% of a Gigabit
which in turn responds with a Delay Response message. The Ethernet link.
measured round-trip time between sending the Delay Request and
receiving the Delay Response is divided by two to determine the The situation changes when network links are operated closer to
path delay. capacity, which is more likely to happen in a converged network
"I know that a Sync message from the Leader Clock takes that combines all traffic of multiple departments on the same
00:00:02 h to reach me. This means that I must add this time physical network, and especially across multiple switch hops. In
to the value of every Sync message before applying the this regard, it is irrelevant whether the network is subdivided into
conversion formula." V-LANs, since traffic of multiple V-LANs competes for the same
bandwidth and scheduling queues when traversing inter-switch
links.
Being able to convert the time stamp of Sync messages to their
internal time and knowing the path delay allows multiple Strict Priority scheduling under high load can lead to bursts in
endstations to play out a given audio sample at the desired time traffic as accumulated lower-priority data that has been buffered
coherently. by switches while forwarding higher-priority packets is transmitted
all at once. This can overload ingress buffers on switches
This process is called "End-to-End Synchronization" because the downstream when converging with other traffic, and results in
Delay messages traverse the whole network, from Follower to significant variations in throughput latency and late, or worst case,
Leader Clock, and back. dropped packets.
PTPv1: End-to-End synchronization In the same way, the path delay of Delay Request/Response
messages can vary significantly when traversing the network to the
Follower
Clock
Leader
Clock Leader Clock and back. As the calculation of the synchronization
offset assumes a path delay that is identical for both directions, this
legacy switches introduces timing errors ("jitter"), which also vary with network
Delay Request
load. Audio systems with many endstations that are expected to
Delay Response play out audio at the same time suffer from degraded coherence
when this happens.
Delay Request & Response traverse whole network
PTPv1: End-to-End synchronization at high network load
Synchronization via PTPv2
First published in 2008, PTPv2 is an improvement over PTPv1 that Follower
Clock Unknown & asymmetrical residence times
Leader
Clock
makes it suitable for large networks at high load and with a high ? ? ? ?
endstation count. Specifically, PTPv2 introduces the option to legacy switches
utilize specific network switches which are "time-aware".
In contrast to legacy switches, instead of just forwarding packets,
time-aware switches know the residence time of packets within the Follower
switch and add this information to the packets. This makes the Clock
?
determination of path delay much more precise. However, PTPv2
is not downward-compatible to PTPv1. Common protocols that
utilize PTPv2 are AES67 and Ravenna. ∆t Loss of coherence at high network load through sync jitter

TI 370 Media Integrated

6 Local Area Networking (Milan™), 1.1 en
 Relevant technical background

2.4 Technical improvements of TSN Additional traffic shaping to avoid bursts of packets
TSN is still based on Ethernet, but it adds a collection of standards Traffic shaping describes methods by which switches manage their
geared at maintaining Quality of Service regarding packet throughput. In the context of real-time media transport, this
synchronization and latency in converged networks at high load. relates to ensuring that important data (such as synchronization
Compliant devices (endstations and switches) implement these and media data) is forwarded without significant variations in
standards at the hard- and firmware level, which means they do latency. Strict Priority forwarding as described before is a basic
not need additional user configuration. This results in the following form of traffic shaping, as it prioritizes certain packets over others
relevant functionalities. without any further constraints.
Synchronization of all network devices including the TSN still uses a Strict Priority Scheduler, but precedes it, in case of
network switches Milan, with a Credit Based Shaper. This packet processing stage
TSN implements a special profile of PTPv2, called Generalized also distinguishes different classes of service but assigns "Credits"
Precision Time Protocol (gPTP), which was first published in 2011 or "forwarding rights" according to class. High priority packets are
and formally added to PTPv2 in 2019. Some of the main still treated as such but are not fed into the Strict Priority Scheduler
differences are that it supports Layer 2 transport exclusively and without regard to other classes of traffic, even when arriving at the
that it mandates the use of time-aware network hardware switch in bursts. The outcome is traffic that is not exiting switches in
instead of just making it an option. monolithic bursts but evenly distributed over time and with different
This also means that TSN does not deal with IP addresses at all, priority classes interleaved. For the price of a small additional
which would be OSI Layer 3. overall latency, this keeps end-to-end latency deterministic and
avoids dropped packets even at high network load.
gPTP implements Peer-to-Peer (P2P) instead of End-to-End (E2E)
synchronization, which means that Sync and Delay messages do High priority traffic
not traverse the whole network, but only travel one hop to an Lower priority traffic schematic drawing
adjacent switch. This is possible because all switches on the
network must be time aware.
As a benefit, timing stability is almost unaffected by network size bursty incoming traffic
and even by extreme load conditions, staying within fractions of a
microsecond at worst. This is in stark opposition to PTPv1
environments, where variations can reach several orders of
Switch
magnitude at high network load. In addition, P2P synchronization Class A
considerably reduces the required network traffic and shortens
sync times.
Credit
The Leader Clock, called a Grandmaster in gPTP terminology, is
still elected automatically. Switches are favoured over endstations
Based
Shaper +
by the election algorithm. Strict
Priority
gPTP: Peer-to-Peer synchronization Class B Scheduler

Endstation Endstation
Known & compensated residence time

time-aware switches Grandmaster

evenly distributed outgoing traffic

Delay Request & Response
only travel one hop

Endstation

Coherence even at high network load

TI 370 Media Integrated

Local Area Networking (Milan™), 1.1 en 7
 Relevant technical background

Bandwidth reservation 2.5 TSN Profiles

TSN employs bandwidth reservation, which works in several steps The general functionalities of TSN, combined with specific
to ensure that the network is: implementations in its various profiles, make TSN suitable not only
a. capable of transporting a media stream between the Talker for real-time media transport, but also for other highly time-sensitive
(sending endstation) and a specific Listener (endstation that applications that require tightly bounded latency. Examples are fly-
shall receive the media stream) before a transmission is by-wire controls in aviation, milling machines or beam-steering
started in terms of available vs. required bandwidth and antennas for mobile networks. TSN allows for them to be remotely
b. that an ongoing transmission cannot be interrupted by other operated over a network without requiring local control units to
traffic. achieve the desired performance and accuracy.
Strictly speaking, not all TSN profiles implement bandwidth TSN therefore offers profiles for different industries, which
reservation in the same way, but for simplicity, the explanation implement specific functionalities as suitable.
given here relates to the ProAV profile. ▪ Automotive
▪ Industrial Automation
Up to 75% of a link’s bandwidth can be dynamically reserved for ▪ Power Generation
TSN traffic. All bandwidth not currently in use for TSN traffic, but ▪ Mobile Communications
at least 25% of a link’s capacity, is therefore available for legacy ▪ ProAV
traffic.
AVB is TSN’s ProAV Profile.
The network switches which must implement the necessary Stream
Reservation Protocol (SRP), play a key role in this process, which
works as follows:
1. The Talker advertises a stream to the network via multicast.
Amongst other data, this Talker Advertise message contains
information about the required bandwidth.
2. As it propagates through the network, every switch along the
way reserves the needed bandwidth on the ingress port and
declares it on all egress ports, if available.
3. If at any point, the bandwidth is not available, the switch
returns Talker Failed to the Talker.
4. If a Talker Advertise reaches a Listener that intends to
subscribe to this stream, it returns a Listener Ready message to
the Talker along the same path.
5. This locks in the reservation in all switches along the path and
initiates the actual stream on part of the Listener as soon as it
receives the Listener Ready message.
6. Successfully reserved bandwidth cannot be used by other
traffic and can only be actively released by the Talker or
Listener or by the network being severed for long enough.

TI 370 Media Integrated

8 Local Area Networking (Milan™), 1.1 en
3 Specifics of AVB and Milan
Specifics of AVB and Milan

3.1 Stream-based media transport, Dynamic Functionally, Dynamic Mapping as shown in the previous example
Mapping, and patching can be illustrated as shown below.
Milan streams Dynamic Mapping
AVB, and with it, Milan, transports audio in streams. A stream is a Functional illustration
container that encapsulates a defined number of audio channels Listener
of a given format (AM824 for legacy AVB, AAF for Milan). There (8 ch)
can also be streams that only contain clock information, but no OUT
audio (CRF streams, see also section gPTP and Media Clock Talker
Domains). (4 ch)
IN
In this context, all streams are transmitted as Multicast, which
means that a Talker needs to transmit a stream only once,
In total, Dynamic Mapping allows the user to tailor the stream
regardless of how many Listeners shall receive it.
output to physical output assignment of a Listener to requirements
Handling streams, whether as a Talker or a Listener, is a processor- imposed by the application or the Talker and facilitates stream-
intensive task, much more so than having more channels per based patching of audio connections which is operationally
stream. There is no general standard about how many Talker quicker than channel-based patches by saving mouse clicks. A
and/or Listener streams an endstation must provide or handle. The typical application would be sending the customary set of
count varies based on the make and model of endstation, intended L/R/SUB/FILL audio signals to many endstations.
use and internal processing capabilities. Therefore, it is a relevant
Depending on the controller software used, a procedure that looks
parameter to know when designing a system.
like channel-based patching on the GUI is also possible, even
Dynamic Mapping - internal routing in Milan though it still works with streams and all their requirements and
endstations constraints in the background. In this case, erasing all Dynamic
To give greater flexibility and to manage streams more efficiently, Mappings in the Listener beforehand is recommended. The
all Milan endstations with Listener capability provide an internal controller software will establish and remove them automatically
routing function, called Dynamic Mapping, between Listener based on the patching operations by the user.
streams and their physical outputs.
Milan endstations with Talker capability may also offer this to
flexibly route physical inputs to Talker stream inputs, but it is not
mandatory.
In the example shown here, a Listener shall output four audio
channels (L, R, SUB, Fill) from a Listener stream to two physical
outputs each. Without Dynamic Mapping, this would require two
Listener streams. Also, it would still result in a lot of mouse clicks
when using a channel-based patching approach.
Dynamic Mapping allows the duplication of audio signals from a
Listener stream output to multiple physical outputs within a listener,
as shown on the right, necessitating only one stream in total in
such cases.
Stream requirements without Dynamic Mapping Stream requirements with Dynamic Mapping

Listener stream 1 Physical outputs Listener stream 1 Physical outputs

Stream outputs Stream outputs

1 (L) 1 1 (L) 1
2 (R) 2 2 (R) 2
3 (SUB) 3 3 (SUB) 3
4 (FILL) 4 4 (FILL) 4
5 5
Listener stream 2
6 6
Stream outputs 7 7
1 (L) 8 8
2 (R)
3 (SUB)
4 (FILL) 2 streams needed One stream, output duplication
to duplicate outputs via Dynamic Mapping in Listener

TI 370 Media Integrated

Local Area Networking (Milan™), 1.1 en 9
 Specifics of AVB and Milan

3.2 gPTP and Media Clock Domains Media Clock extraction directly from an audio stream
gPTP establishes a common general time reference, delivered by As an alternative to a CRF stream, Listeners can also extract the
the gPTP Grandmaster, also termed a "wall clock" for this reason, Media Clock from an audio stream they receive. This method is
for all network nodes, which then form a gPTP Domain. The gPTP used in simple devices which can only receive one stream in total
Grandmaster is elected automatically out of all endstations and and therefore do not have the capacity for a separate CRF stream
switches on the network, whereby switches have a higher priority in addition to the AAF audio stream. In this case, the Listener joins
than endstations in the election process. the Media Clock Domain of the respective Talker.
gPTP Domains can only be formed and audio can only be passed
between endstations connected by AVB switches. Inserting a 3.3 Latency
legacy switch into a gPTP Domain splits it into two independent Transporting a stream from Talker to Listener through the network
gPTP Domains with their own gPTP Grandmasters. needs time, mostly for traversing switches. The system must account
for this latency by setting an appropriate user-defined value in the
gPTP Domain 1 gPTP Domain 2 Talker. It can be set in steps between 125 µs and 2 ms.
legacy
switch
The link speed and the associated worst-case latency per hop
determine the permissible number of hops between Talker and
no gPTP sync/
gPTP
Grandmaster
Listener.
gPTP audio transport
between
Grandmaster gPTP Domains 100 Mbit/s 1 Gbit/s
network network
AVB Switch
Latency per hop 280 µs 140 µs
Listener (worst case)
Max hops within 7 14
Media Clock via Clock Reference stream
2 ms
In addition to a gPTP Grandmaster, endstations need a common
rate at which samples are played out or recorded. This "Media Max number of 6 13
Clock" is therefore different from the wall clock but relates to it, as switches between
sets of samples are delivered with a gPTP "Presentation time" and Talker and Listener
then processed at the specified sample rate. within 2 ms
Out of all endstations, a Media Clock Reference must be selected
manually. This device then distributes its Media Clock as a A realistic scenario that uses a 1 Gbit/s network should never
separate Clock Reference Format stream (CRF stream). All exceed the maximum possible hop count, and shorter latencies
endstations which subscribe to the same Media Clock Reference than 2 ms can usually be set. 1 ms (= 1000 µs) should account for
form a Media Clock Domain. all reasonable topologies, as illustrated by the graphic below.
Using infrastructure-sized switches at FOH and in every amp city, a
Multiple Media Clock Domains with arbitrary sampling rates and
system rarely exceeds 5 hops.
their own Media Clock References and associated CRF streams
can coexist within the same gPTP Domain on the same LAN. FOH STAGE
Media (audio/video) can only be shared within the same Media
Clock Domain. 140 s 140 s 140 s
L
1 2 3
gPTP Domain DN1
FOH 4
D40
140 s

Talker switch D40 =560 s

D40
Listener

Talker 140 s 3 System rack

with DN1 switch
gPTP
Media Clock Reference Grandmaster Listener 140 s
R 4
DN1
5
AVB switch D40
140 s

D40 =700 s
D40
Listener
Listener Listener System rack
Media Clock Reference with DN1 switch
Media Clock Domain 1
Media Clock Domain 2

Specially equipped endstations can also be part of multiple Media

Clock Domains. A typical application would be a matrix processor
that routes audio signals between different rooms in a multi-venue
building which are otherwise separate Media Clock Domains.
However, this requires these endstations to perform internal
sample rate conversion, which is why it is not a general feature.

TI 370 Media Integrated

10 Local Area Networking (Milan™), 1.1 en
 Specifics of AVB and Milan

3.4 Endstation naming

Milan endstations offer several naming options to help with the
functional structuring of a system (examples in brackets). Names
can be freely assigned and do not impact patches.
▪ Group name (e.g. "FOH", "Stage")
▪ Endstation name (e.g. "Main console 1")
▪ Stream name (e.g. "Playback tracks" for Listener streams, "PA
feed" for Talker streams)
▪ Channel name (e.g. "Stem 1 L", "Stem 1 R" for Listener
channels, "L", "R", "SUB", "FILL" for Talker channels).

3.5 Interoperability definitions of Milan

While AVB as TSN’s ProAV profile defines general attributes,
further standardization is necessary to assure interoperability
between devices of different manufacturers, which makes the
technology usable in typical, heterogenous applications.
These additional constraints, as defined by the Avnu, are the Milan
protocol. While it contains more details at the protocol level, the
user-relevant specifications are described below.
Stream formats
Endstations can only transmit to one another if they use a common
stream format. Thus, every Milan endstation must support at least
one Listener stream of the following properties.

Audio format AAF

Channel count 1, 2, 4, 6, 8
Sampling rate 48 kHz or 96 kHz or 192 kHz
Sample bit depth 32 bits

The total number of Talker and Listener streams per endstation

varies and depends on the device, its physical I/O count and
resources and its intended application.
Redundancy
Every Milan endstation may but does not have to support
redundancy. This is enacted using two designated network
interfaces on the endstation (PRImary and SECondary), which are
connected to separate primary and secondary physical networks.
Redundancy does not change the available stream count on
endstations. I.e., an endstation with two Listener streams and a
primary and secondary network interface supports two Listener
streams per interface, but not four Listener streams on the primary
interface if the secondary connection is not in use.

TI 370 Media Integrated

Local Area Networking (Milan™), 1.1 en 11
4 Best practices
Best practices

4.1 How to set up a Milan-based system Redundancy check

When using redundant networks, it makes sense to check both the
Topology
primary and secondary network individually. While d&b system
▪ Use only AVB-certified switches to interconnect Milan
amplifiers and audio network bridges indicate the presence of the
endstations. Some switches might need to be set to "AVB
respective Talker for both networks, it is still meaningful to check
mode".
manually, especially when using heterogenous systems:
▪ Deploy your network in a star topology to minimize the number
of hops. Place switches with enough ports at FOH and in every ▪ When all streams are patched and audio is playing, first
amp city. Connect everything (consoles, matrix processors, physically disconnect the primary network from the Talker.
stage boxes, system amplifier racks with AVB endpoint Audio should not be interrupted.
switches) to these central switches and avoid daisy-chaining of ▪ Reconnect the primary network and wait for it to synchronise
racks or other equipment. and settle. This process takes at least 10 s.
▪ Consider fiber links for the FOH to stage connection. Typical ▪ Once the system indicates sync and has settled, disconnect the
cable lengths of 80 - 100 m are at the limit of what copper secondary network. Again, audio should not be interrupted at
cables are capable of. any endstation.
▪ If possible, use only etherCON connectors for copper links for
a more robust mechanical connection to the individual devices.
▪ In case of redundant links, do not run the primary and
secondary network cables next to one another from FOH to
stage, if possible, to prevent one physical event from severing
both at the same time.
Note: Usually, AVB switches only support one gPTP Domain
per switch. It is technically not possible (and it would not be a
promising idea from a redundancy point of view) to enact a
redundant AVB network using two V-LANs on the same switch.

Talker configuration
▪ Determine the worst-case number of hops in your network by
counting the switches between your Talker(s) and the farthest
Listener(s). On a 1 GBit/s network, the expected maximum
network latency for your worst-case path is:

▪ Set your Talker to this value or the next higher one if the exact
value is not available. Common controller software will also
issue a warning if the actual value exceeds the configured
latency.
Sampling rate
Set your sampling rate before patching any channels or streams.
Changing it later will interrupt audio reproduction.
Media Clock Reference/Media Clock Domain
Associate all desired endstations to the same Media Clock
Domain by subscribing them to the same CRF stream/assigning
them to the same Media Clock Domain in the respective dialog
(controller dependent).
Patching: Streams or channels?
▪ Consider patching streams instead of individual channels. For
example, typical PA applications benefit from having L/R/SUB/
FILL available at every system amplifier and using the input
routing to select the desired channel or matrix them together as
required.
▪ Before patching, check the Dynamic Mapping of all endstations
to avoid unexpected results.

TI 370 Media Integrated

12 Local Area Networking (Milan™), 1.1 en
5 Hive controller quick start guide
Hive controller quick start guide

5.1 Overview over the most important controls

Even though it is not the final and only Milan controller software,
Hive is relatively widespread. This section gives a quick overview
of its basic operation.

TI 370 Media Integrated

Local Area Networking (Milan™), 1.1 en 13
 Hive controller quick start guide

5.2 Basic configuration and use

Configure interface
Þ From the «View» menu select:
▪ Controller Toolbar
▪ Utilities Toolbar
▪ Discovered Entities

Select network interface

Þ Use the drop-down menu to select the correct network
interface of your computer.
↳ No IP address configuration is required.
If in doubt, make sure your firewall does not block the
application.
Discovered endstations ("Entities") should appear after a
few seconds.

Configure endstations
Apart from names, endstations can only be reconfigured if no
streams are connected to them.
1. Disconnect the respective endstation if necessary or use the
"Disconnect all streams" button.
2. Double click an endstation in the list to open its Device View.
3. Configure:
▪ Sampling rate
▪ Latency (if this endstation is the Talker)
▪ Names
▪ Stream formats for Listener and Talker streams

TI 370 Media Integrated

14 Local Area Networking (Milan™), 1.1 en
 Hive controller quick start guide

Configure a Media Clock Domain

1. Open Media Clock Management.
2. Add a Media Clock Domain by clicking «(+)».
3. Assign endstations to the Media Clock Domain.
4. Set the Media Clock Reference in the "Master" column.

Þ In the connection matrix, this will show up as a connected CRF

stream.

TI 370 Media Integrated

Local Area Networking (Milan™), 1.1 en 15
 Hive controller quick start guide

Check/configure Dynamic Mapping

1. Right click an endstation in the Listener row to configure its
Dynamic Mapping.
↳ To prepare for channel-based patching, delete all the links
of Listener streams to physical outputs. Drag from the
physical output into a white area.
To prepare for stream-based patching, configure the links
of Listener streams to physical outputs as required by
dragging from a stream channel to the physical output.
Several physical outputs can be connected to one stream
channel.
2. Double check the Talker stream Dynamic Mapping (insofar
the endstation supports it) by right clicking the Talker in the
Talker column.

Patching
Þ Set marks in the connection matrix to patch or unpatch as
required.

Error handling
Unplugging a patched endstation will raise an error in the "Status"
column.
Þ Clear by clicking "Clear errors."
↳ Refresh view.

TI 370 Media Integrated

16 Local Area Networking (Milan™), 1.1 en
6 Glossary
Glossary

Bounded latency Stream

Bounded latency for packets means that the time they require to A stream is a container that contains a defined number of audio
travel through a network is guaranteed not to exceed a pregiven channels of a given format. There can also be streams that only
value. It is one of the key factors in a TSN network. contain clock information, but no audio. In a TSN network, all
streams are transmitted as Multicast. Multicast means that even if
Bridge there are multiple Listeners for a specific stream, the Talker needs
The technical term for "switch" used by the IEEE. to transmit it only once. This is opposed to Unicast, where every
Listener receives its own stream, even if it contains the same audio
Converged network
channels as an existing one, multiplying the network load for the
This term describes a network that combines all network-based
Talker.
communication, e.g., media transport and control data of all kinds.
This contrasts with using multiple logically or physically separate Talker
networks. Converged networks mandate standards and hardware A Talker is an endstation that can send streams.
that guarantee precise synchronization and bounded latency to
function. Time aware switch
In legacy switches, the residence time of a packet (the time
Endstation required for a packet to ingress the switch, get processed, and
An endstation is any network device that provides audio I/O and egress again) is unknown to the switch. This adds unknowns to the
that is not exclusively a switch. determination of path delay which in term causes synchronization
jitter. Time aware switches do have a concept of time. They add
gPTP Grandmaster
information about the residence time to packets, so that the
The Grandmaster is the central clock within a TSN network, also
synchronization process can take it into account. The Avnu
termed the "wall clock" (visible to all devices on the network) that
Alliance Certified Product Registry lists all certified endstations and
provides a common time reference with nanosecond precision.
switches:
Out of all endstations and switches on the network, the
Grandmaster is automatically elected using the Best time https://avnu.org/certified-product-registry/
Transmitter Clock Algorithm (BTCA). The algorithm favours Traffic shaping
switches over endstations. Traffic shaping is a technique to manage bandwidth utilization in a
IEEE data networks to optimize or guarantee performance by
The Institute of Electrical and Electronics Engineers is one of the preventing congestion. A traffic shaper handles different kinds of
leading associations for electronics and electrical engineering and packets by predefined rules which govern the rate at which they
related disciplines. It has published a significant amount of the can be sent.
world’s professional literature in the related fields and hosts many
standardization committees that define the design and interaction
of devices and applications in many technical fields.
Listener
A Listener is an endstation that can receive streams.
Media Clock Domain
All endstations in an AVB network that shall exchange audio must
be part of the same Media Clock Domain. This means that they all
follow the same Media Clock Reference regarding the rate at
which they play out or record audio samples. There can be
multiple Media Clock Domains in the same physical AVB network,
each with their own Media Clock Reference.
Media Clock Reference
The Media Clock Reference (previous known as Media Clock
Master) provides the rate at which samples are played out within
a Media Clock Domain. In contrast to the gPTP Grandmaster, this
is not a "time of day" index. Blocks of samples in a Milan AAF
stream contain a presentation time that relates to the gPTP
Grandmaster time at which the first sample shall be played out,
with the subsequent samples following at the rate given by the
Media Clock Reference.
Presentation time
The gPTP Grandmaster time index, set by the Talker, at which a
sample is to be played out by Listener.

TI 370 Media Integrated

Local Area Networking (Milan™), 1.1 en 17
www.dbaudio.com
370

D5370.EN .01, 04/2024 © d&b audiotechnik GmbH & Co. KG