Concepts
This page explains the networking concepts Milan Manager is built on and why they exist. The tab reference pages describe how the controls are operated. This page provides the background needed to understand what those controls change in the network.
AVB and Milan
Standard Ethernet delivers data on a best-effort basis: packets may be delayed or dropped when the network is busy. For live audio, late data is as unusable as lost data. Audio Video Bridging (AVB) is a set of IEEE standards that adds the guarantees required for real-time audio to Ethernet:
| Mechanism | Standard | Purpose |
|---|---|---|
| gPTP | IEEE 802.1AS | Provides a common time base to all devices. See Time and clock. |
| Stream reservation (SRP) | IEEE 802.1Qat | Reserves bandwidth for each stream along its path through the network, so audio never competes with other traffic. |
| Forwarding and queuing | IEEE 802.1Qav | Prioritizes reserved streams in every switch, which keeps the transmission delay bounded. |
| AVTP | IEEE 1722 | Defines the packet format carrying audio samples in streams. |
| AVDECC | IEEE 1722.1 | Discovers, enumerates, connects, and controls devices. Milan Manager uses AVDECC to find devices and change their settings. |
The AVB standards leave many choices open, such as stream formats, clock distribution, and redundancy. As a result, AVB devices from different vendors do not necessarily work together. Milan is a specification by the AVnu Alliance that fixes these choices, so that Milan-certified devices from different vendors interoperate. The Devices tab shows whether a device reports Milan certification.
AVB Domain
The guarantees of AVB only apply where every switch along the path supports AVB. The AVB domain is the set of devices and AVB-capable switches between which streams can be reserved.
A switch without AVB support forms the boundary of the AVB domain. Devices behind such a switch may still appear in Milan Manager, because device discovery uses ordinary network traffic. Streams to or from these devices, however, cannot be reserved and do not transmit audio.
Milan Manager monitors and controls the AVB domain reachable through the selected network interface (see Connect to a network). The Network tab displays its topology.
Talkers, Listeners, Streams, and Channels
Audio travels through a Milan network on two levels:
- Stream connections: a talker sends audio in streams. Each stream carries a fixed number of channels in a defined stream format. A listener receives a stream by connecting one of its input streams to an output stream of the talker. A single talker stream can be received by any number of listeners while being transmitted only once per network link.
- Channel mappings: inside each device, mappings define which audio channel is placed into which slot of an output stream (talker mapping), and which slot of an input stream feeds which audio channel (listener mapping).
Network resources such as reserved bandwidth are allocated per stream. Grouping channels into streams keeps the number of reservations low, while channel mappings retain the flexibility to route individual channels.
This two-level model has the following consequences in Milan Manager:
- Each device offers a fixed number of input and output streams. Once all of them are in use, no further stream can be connected, as indicated by the 'Connect streams (x left)' label in the Routing tab.
- Talker and listener streams must use a compatible stream format, which includes the number of channels and the sampling rate. Devices running at different sampling rates cannot exchange streams.
- A talker stream may already be received by several listeners. Modifying its talker mapping changes the audio for all of them and temporarily interrupts audio on that stream. For this reason, editing talker mappings in Streams mode must be started explicitly (see Mapping for talkers).
Channels Mode and Streams Mode
The two routing workflows correspond to the two levels described above:
- In Streams mode, stream connections and channel mappings are edited directly, in the stream matrix of the Overview tab and the mapping matrix of the Routing tab.
- In Channels mode, only the desired channel connection is specified. Milan Manager derives the required stream connections and channel mappings automatically.
Automatic Connection Handling
Streams are a limited resource, and changes to a talker mapping interrupt audio. For each requested channel connection, Milan Manager therefore chooses the least intrusive option available, in the following order of preference:
| Preference | Situation | Change applied |
|---|---|---|
| 1 | The listener already receives a talker stream that carries the channel. | Only a listener mapping is added. The talker and the network remain unchanged. |
| 2 | The talker channel is already mapped into a talker stream. | A free listener input stream is connected to that talker stream. The talker remains unchanged. |
| 3 | The listener already receives a stream from the talker that has a free slot. | The channel is added to the talker mapping of that stream. No new stream connection is required. |
| 4 | None of the above. | The channel is mapped into a talker stream with a compatible format, and a new stream connection is created. |
To make room in a talker stream, talker mappings that no listener uses may be released. Preferences 3 and 4 modify the talker mapping and may briefly interrupt audio on that stream.
A channel connection cannot be established if one of the following applies:
- The listener has no free input stream.
- No talker stream uses a stream format supported by the listener, for example because of different sampling rates.
- The talker does not support changing its mapping, and no suitable mapping exists yet.
- No suitable talker stream has a free slot left.
In these cases, an information dialog is shown. The 'Streams' toggle in the routing panel provides manual control over which stream carries a channel.
Channels mode operates on primary streams. Secondary streams follow automatically, as described in Redundancy.
Redundancy
In a single network, one failing cable or switch interrupts all audio passing through it. Milan redundancy protects against this by operating two physically independent networks in parallel, the primary and the secondary network.
Redundant devices provide two network ports, one connected to each network. A redundant talker sends every stream on both networks. A redundant listener receives both copies and continues playback from the other network without audible interruption if one of them fails.
Milan Manager handles redundancy as follows:
- Connecting a primary listener stream also connects the corresponding secondary stream, provided both devices support redundancy. Primary and secondary connections are displayed as a single connection with two separate states (see Status information).
- The Network tab reports errors separately for the primary and secondary network and displays the topology of both.
- Redundancy relies on the two networks being separated. A cable or switch connecting both networks removes this independence. Milan Manager reports such a 'Primary & Secondary interconnection' as a severe error.
Time and Clock
A Milan network uses two separate clocks: the network time provided by the gPTP leader, and the audio sample clock provided by the Media Clock leader. Both are often confused because both are related to timing, but they serve different purposes and are selected differently.
| gPTP leader | Media Clock leader | |
|---|---|---|
| Provides | Common network time | Audio sample clock |
| Selected by | The network, automatically | The user, in the Devices tab |
| Scope | One per network (primary and secondary) | One per Media Clock domain |
| Displayed in | Network tab | Devices tab |
gPTP
The generalized Precision Time Protocol (gPTP) gives all devices in the AVB domain a shared sense of time with sub-microsecond accuracy. One device, the gPTP leader, provides the reference time to all others.
The gPTP leader is elected automatically by the devices and switches in the network, based on their clock properties and priority settings. If the gPTP leader disappears, another device takes over. In a redundant setup, the primary and the secondary network each elect their own gPTP leader. Changes of the gPTP leader are recorded in the Event Log.
gPTP defines when something happens, not how fast audio samples are produced. Timestamps based on gPTP time are used to align playback across devices (see Presentation time).
Media Clock
The Media Clock defines the rate at which audio samples are produced and played back. All devices exchanging audio must run on the same Media Clock. Otherwise, their sampling rates drift apart over time, which results in audible clicks or dropouts.
In a Milan network, the Media Clock leader distributes its clock to the other devices in a dedicated clock reference stream. Depending on the device, the leader generates the clock internally or derives it from an external source, such as a word clock input. All devices following the same leader form a Media Clock domain.
The Media Clock leader is selected in the Devices tab. Several Media Clock leaders in the network result in several Media Clock domains. Audio cannot be exchanged reliably between devices of different Media Clock domains, and Milan Manager indicates this state with orange Media Clock icons.
Presentation Time
A talker adds a timestamp to each stream packet, which specifies when the audio has to be played back: the moment of sampling plus the presentation time. Listeners hold the audio until that moment, based on the shared gPTP time. This has two effects:
- All listeners play back the same sample at the same instant, regardless of the number of switches between them and the talker.
- The latency of a stream is constant and known in advance.
The presentation time must exceed the transmission delay to the most distant listener. Audio arriving after its presentation time cannot be played back. For this reason, presentation times that are too short for the currently connected listeners are grayed out and cannot be selected. The presentation time is adjusted per talker stream in the Routing tab (Streams mode) or in the streams view of the Overview tab (Channels mode).