User Guide — Managing AVB Networks

This guide covers the design, management, and best practices for Milan AVB networks connected to Meyer Sound products. Implementing these recommendations results in a stable, high-quality network that connects the system's components. This guide includes the following sections:
Important
This guide does not replace the Institute of Electrical and Electronics Engineers (IEEE) or Avnu Alliance network specifications. See Milan AVB resources to familiarize yourself with these specifications.
Information related to the operation and control of specific Meyer Sound products can be found elsewhere on this site (docs.meyersound.com) and in the instructional videos at meyersound.com/videos.
What is Milan AVB?

Media Integrated Local Area Network (Milan) is a networking protocol developed specifically for professional media networks used in concert venues, theaters, and studios to move audio and video data over Ethernet with guaranteed timing, reliability, and interoperability. Built on the Audio Video Bridging (AVB) standards, the Milan protocol adds further constraints to ensure that networked audio and video devices from different manufacturers work together reliably.
The sections below provide more detail about Milan AVB and how TSN (Time-Sensitive Networking) is the evolution and expansion of AVB.
Milan

Milan is a description of the AVB/TSN standards that provides specifications to ensure the interoperability of pro audio network devices by standardizing the implementation of AVB technology across various manufacturers’ products. The Milan effort takes place under the umbrella of the Avnu Alliance and uses the IEEE AVB/TSN standards.
Meyer Sound offers AVB devices that include AVB controllers, AVB talkers, and AVB listeners.
Milan defines a set of technical profiles, including:
Audio stream formats
Media clocking
Redundancy
Device discovery, connection management, and control audio stream format
Milan uses the AVTP Audio Format (AAF) and supports stream channel counts of 1, 2, 4, 6, and 8. Milan AVB talkers can transmit any or all of the channel counts or sample rates specified. Milan AVB listeners must be capable of receiving audio streams with all of the specified channel counts. Milan AVB talkers must support at least one of the listed sample rates.
Milan-compliant audio stream format
The Milan-compliant audio stream format functions with the following set of parameters:
Data Encapsulation — PCM
Format — AAF
Packet Bit Depth — 32 fixed
Audio Bit Depth — 24
Number of Channels — 1,2,4,6,8
Sample Rates — 48 kHz, 96 kHz
Samples per PDU (Protocol Data Unit) — 6 (48 kHz), 12 (96 kHz)
AVB and TSN

Audio Video Bridging (AVB) is a subset of Time-Sensitive Networking (TSN), which facilitates the transport of high-performance audio and video, and controls an Ethernet Local Area Network (LAN). TSN includes AVB, but also adds new features for broader industries beyond just audio and video, including automotive, industrial automation, and aerospace. AVB is based on open-source IEEE standards. Meyer Sound has implemented these standards in our product designs as the preferred choice for distributing digital audio signals and control.
The AVB/TSN family of standards provides three major enhancements:
Precise timing to support low-jitter media clocks and accurate synchronization of multiple streams.
A simple reservation protocol that allows an application on an endpoint device to reserve the necessary network bandwidth for the complete path from an AVB talker to an AVB listener.
Queuing and forwarding rules ensure the streams will pass through the network within the time specified by the reservation.
Media clocking

The media clock is used as the common clock to synchronize a Milan network. The media clock is carried by the Clock Reference Format stream and can be derived from any Milan audio stream. AVB utilizes the IEEE Generalized Precision Time Protocol (gPTP) to provide an accurate time base across the entire network.
All audio is synchronized across the entire network, regardless of the number of switches. All devices output the same audio data at the same instant.
Connections

Nebra is Meyer Sound's connection manager software, used to make Milan AVB connections and query the network for existing connections. Nebra can also be used to manage media clock streams. Milan utilizes MSRP. When connections are made between AVB talkers and AVB listeners, messages are sent between the selected talker and listener that query each switch in the path to determine if there is enough available bandwidth to make the connection. If there is sufficient available bandwidth, the connection is made between the talker and the listener. If the bandwidth is not available, the connection will not be made and the user will be informed that the attempt failed. If the connection is made using Nebra, the connection details are retained in each device. If the connection is disrupted (a cable is unplugged, a switch or endpoint is powered off, etc.), when the disruption is corrected, the connection will be automatically reestablished, once again capable of transporting audio packets from the talker to the listener.
Note
Connections are only made when the talker and listener sample rates and stream configurations are identical.
Redundancy

The Milan protocol redundancy scheme utilizes duplicate network hardware and infrastructure. Two physically isolated, independent networks are created, each with its own time domain, that are both connected to each device. Milan also defines a mechanism to allow for a transition from one network to the other in the event of a network failure.
Meyer Sound Milan devices

As noted in AVB and TSN, Meyer Sound Milan devices use AVB/TSN networking but follow the strict Milan certification rules for plug-and-play compatibility. All clocking, stream reservation, synchronization, etc., happen automatically; very few manual settings are needed.
An all-Milan system signal path is possible. If Milan AVB connections are made between a mixing console with Milan-certified output capabilities and GALAXY signal processors and PANTHER line arrays, the need for analog or AES3 cabling is eliminated.
Meyer Sound Milan-certified devices include:
Tip
You can see all the current Meyer Sound Milan-certified devices at the Avnu Certified Product Registry.
Galileo GALAXY processor

The Galileo GALAXY digital signal processors (shown below) include an AVB controller and are both AVB talkers and AVB listeners. They can send and receive both AVB streams and Clock Reference Format (CRF) streams. Each processor has two network ports labeled AVB 1 and AVB 2, for discrete primary and secondary network connections.
GALAXY processors can receive Milan-formatted AVB streams. The speed of the connection from the last network switch to each GALAXY is 1000 Mbps. The input format for Milan AVB is AAF PCM-INT-32, 48 kHz, or 96 kHz.
For more information on GALAXY AVB stream formats, see Clocking, in the Galileo GALAXY User Guide.



Note
For more information about the control of GALAXY processors with Nebra software, see the support videos located at meyersound.com/product/galileo-galaxy/#support-videos and the User Guide — Galileo GALAXY.
Meyer Sound Milan endpoint loudspeakers

Meyer Sound Milan-certified endpoint loudspeakers have a Type 3M digital input module, as shown below. This AVB listener input module can receive one Milan-formatted AVB stream. The speed of the connection from the last switch to the endpoint is 100 Mbps. The endpoint input format is Milan AVB, AAF PCM-INT-32, 96 kHz, and the media clock is recovered from the incoming audio stream.

NADIA digital audio platform

The NADIA-CP core processor (rear panel shown below) controls and matrixes audio on discrete Constellation and Matrix partitions. The NADIA-CP core processor can send and receive AVB audio streams to and from NADIA-AI12 input modules, NADIA-AO16 output modules, Galileo GALAXY digital signal processors, or any other Milan device. The speed of the connection from the last network switch to any of the NADIA modules is 1000 Mbps. The input format for Milan AVB is AAF PCM-INT-32, 96 kHz.

Network redundancy options
![]() |
Meyer Sound recommends using the Milan redundant topology wherever possible. AVB networks can be configured in a variety of ways; more robust configurations come at the expense of additional network switches. Recognizing that specific applications may have restrictions in terms of cost or special requirements, alternative topologies are illustrated in the following section. It is the responsibility of the system designer to balance the specific system requirements against the available resources for any specific application.
Note
When connecting Meyer Sound legacy RMServers or third-party devices that might flood the network with multicast streams or non-AAF/CRF packets that could be received by a Galileo GALAXY processor, make the connection to a switch connected to the secondary network or to the AVB 2 port of the Galileo GALAXY processor. Connecting these devices to the primary network or Galileo GALAXY processor AVB 1 can cause unstable network behavior in extreme cases involving many devices (100+) or large amounts of multicast traffic.
Some of our products include analog inputs in addition to the Milan endpoint. The analog input can serve as a backup to the Milan connection. However, this requires manually muting the signal sent to the Milan input and unmuting the signal sent to the analog input in the event of a network failure.
Caution
In network configurations where multiple paths can exist, a failure that triggers a Rapid Spanning Tree Protocol (RSTP) failover can result in a different path length, which would result in the system recalculating latency. Thus, Meyer Sound recommends using a fully redundant (Milan redundancy) network. For the other options shown below, RSTP should be disabled on network devices (usually switches) to ensure the network topologies perform as described. If network switches do not have RSTP disabled and are connected to networks that are not fully redundant, redundancy and overall network operation may not behave as expected. See the User Guide — Galileo GALAXY AVB Extreme Switch Configuration for instructions on configuring Extreme Networks switches with RSTP disabled.
Milan redundancy
The Milan standard defines the most robust network configuration as a fully redundant network. This topology uses two independent networks, both distributing audio signals simultaneously. In the event of a network failure, there is no pause or drop in audio, as audio is already being transmitted across the secondary network.
Galileo GALAXY processors support Milan redundancy, an option defined in the Milan standard as a fully redundant network, illustrated below.

A control computer running Nebra control software can be connected to either network. If control redundancy is desired, a second computer can be connected to the other network, or a second network interface card in the same computer can be connected to the other network.
For GALAXY processors and NADIA modules, always connect the primary network to the AVB 1 port and the secondary network to the AVB 2 port. The diagram below shows one possible configuration of Milan redundancy.

Note
Loudspeakers with Milan endpoint modules are not shown for clarity. These loudspeakers are also connected to the network switches. Loudspeakers equipped with Milan Endpoint Type 3M modules are connected to only the primary network.
Primary network-only — no redundancy

The non-redundant, primary network-only configuration is the simplest and least robust configuration option. Each GALAXY processor's AVB 1 port is connected to the network switch. The AVB 2 port is not used. A fault of any single cable, network switch, or AVB entity will result in at least a partial loss of audio and/or control.

Meyer Sound Milan endpoint loudspeaker network connections

Meyer Sound loudspeakers equipped with Milan Endpoint Type 3M input modules derive their media clock from the incoming AVB stream. Subscription to the CRF stream is not necessary.
The Milan Endpoint Type 3M input module includes one network connection, as shown in the illustration below of a typical primary-only connection network. This single network connection presents the following limitations:
Redundancy schemes are not possible between the last switch and a loudspeaker.
Multiple Milan endpoints can subscribe to the same AVB stream/channel; however, looping the network connection from one loudspeaker to another is not possible. Each loudspeaker is connected directly to a switch.
Milan endpoint-equipped loudspeakers subscribe to only one AVB stream at a time and only one channel of that stream.

Meyer Sound Milan AVB networking best practices
![]() |
There are a number of ways to ensure a stable AVB network by using some best practices related to network operations, AVB devices, bandwidth, wiring, and clocking.
Implement the following guidelines for best results with Meyer Sound Milan AVB devices:
Follow the order of operations

One of the most helpful techniques to ensure expected network performance is to follow a prescribed order of operations when connecting and utilizing an AVB network. The order in which devices are powered on, cable connections are made, and devices are manipulated by AVB controllers can affect network behavior. This is the prescribed order of operations:
Make all physical network connections before applying power to any device. Before AVB devices are powered on, all wiring connections should be made, including AVB talkers, AVB listeners, and network switches.
When possible, apply power to all devices simultaneously. This approach creates an environment where discovery between devices happens simultaneously and avoids possible network confusion when devices are added to the network infrastructure one at a time.
Name entities and groups. Entity and group names identify devices and are used as part of the stream or channel names. Each entity and group should be given a unique and identifiable name. For Meyer Sound devices, the entity and group names can be changed using Nebra software.
Connect clocks before distributing audio. For Galileo GALAXY processors, select one of the three different clock mode options in Nebra software:
Internal
AVB clock CRF
AVB input
Internal is selected if the GALAXY is going to be the CRF source. AVB clock CRF is selected if the GALAXY processor will be locked to a selected CRF source. The media clock can also be recovered from an AVB stream, allowing you to select an AVB input that has been connected to an AVB stream.
Route audio between devices. Establish audio connections between talkers and listeners. Talkers advertise their available streams to the network. Meyer Sound’s Nebra software includes a connection manager that lists all available talker and listener channels and establishes AVB connections between the talkers and listeners.
Tip
If devices are added to an existing network and unexpected behavior results, powering down all AVB devices and following the prescribed order of operations is a good first troubleshooting step.
Use the CRF stream for media clocks

The CRF stream is a compact and efficient way of distributing a media clock. Meyer Sound recommends using this option when available to ensure that all devices are using the same media clock source and to efficiently utilize the bandwidth of the network.
Do not mix or cascade media clocks

Caution
Never mix or cascade media clocks. Use the same Clock Reference Format (CRF) or AVTP Audio Format (AAF) stream to provide the media clock to all devices in a system. Even small timing differences between devices can cause audible audio degradation.
In a given AVB domain, all devices that will send/receive audio must either lock to the same media clock or use sample rate converters. A media clock source is any Milan AVB device that can transmit an AAF stream or a CRF stream. A Galileo GALAXY processor can be a media clock source and can transmit both AAF and CRF streams. All AVB listeners in a domain that can receive CRF streams should be subscribed to the same CRF stream source. If a Listener cannot be set to listen to a CRF stream, it must either recover the clock from the incoming AAF stream or use input sample rate converters.
Use a common system clock for multiple interconnected GALAXY processors

When multiple Galileo GALAXY processors are part of the same system, all processors should subscribe to the same media clock source. Media clocks should never be daisy-chained. Even minor timing differences can cause audible audio degradation. The figures below illustrate common media clock distribution methods when multiple GALAXY processors connect to the same AVB network.
The system in the figure below shows GALAXY 1 designated as the media clock. In software, select Internal for GALAXY 1's media clock source. Select GALAXY 1 as the media clock source for all other processors.

The example below shows the AES3 signal aligned to a word clock sent through several GALAXY processors. Again, the media clock cannot be daisy-chained, unlike the audio signals. In this case, if GALAXY A (which must be a legacy GALAXY 816-AES3) receives an AES3 input synchronized at its source to a word clock, set its system clock to the word clock received from the same source via the BNC connector. In this case, you must disable the Asynchronous Sample Rate Converter (ASRC) of the GALAXY input(s).
The other GALAXY processors (any model GALAXY B, C, D, and E) must receive their media clock from the same source as GALAXY A. This configuration is achieved by selecting GALAXY A as the media clock source for GALAXY processors B, C, D, and E.

The figure below illustrates a case where a Milan AVB signal is received by the first GALAXY processor and must be routed to additional GALAXY processors. Because the same media clock must be used for all AVB devices that send and receive audio, either a common CRF stream can be used, or the media clock can be recovered from the incoming Milan AVB stream. To recover the media clock from the received AVB stream, route the same Milan AVB stream to each of the GALAXY processors. Each GALAXY processor must then have its System Clock > Clock Mode set to use the AVB input with the common AVB stream. If the Milan AVB source can provide a CRF stream, then a dedicated input on each GALAXY is not necessary; instead, the GALAXY processors can all be set to use the same CRF stream for their System Clock > Clock Mode.

Consider reducing presentation time
![]() |
Initially, when making AVB connections, presentation time defaults to a value of 2 ms. You can reduce the value manually when necessary. Remember, for sound propagation in air, 2 ms equals roughly 1.8 feet.
Below are additional details related to the presentation time of a Milan AVB system, which will help you determine adjustments for the default setting.
Because all AVB devices on a network use a common time reference, Generalized Precision Time Protocol (gPTP), and the network knows the transmission time between AVB talker and AVB listener, the talker includes a time stamp, set in the future, for “presenting” the signal at the input of the listener - the presentation time. Including that time stamp ensures that all listeners reproduce the signal simultaneously, regardless of the different transmission paths between talkers and listeners. Systems with many network switches will have a slower presentation time than those with very few.
In the figure below, loudspeaker Pairs #1, #2, and #3 are 2, 3, and 4 switch hops away from the GALAXY processor. An AVB controller can report the time it takes to reach the most distant device, in this case, Pair #3. Each time data packets pass through a network switch, a small amount of latency (delay) is added. For example, a typical 1 GbE-capable (1,000 Mbps) network switch may add 150 nanoseconds of latency for each switch hop. In that case, Pair #2 receives the same stream 150ns later than Pair #1 does. Each talker and listener may have additional sources of delay, including conversion and signal processing. Meyer Sound software reports the Multiple Stream Reservation Protocol (MSRP) accumulated latency and the presentation time offset of a received stream.

Milan AVB defaults to using a presentation time of 2 ms. This time allows for approximately 12 hops at 1 GbE or about 7 hops at 100 Mbps connection speeds. In applications where signal latency must be reduced to the absolute minimum, the default 2 ms presentation time can be reduced, provided allowances are made for the transit time through the actual number of switches, along with a reasonable amount of additional time for processing overhead at the endpoints. Control software allows manual adjustment of the AVB talker stream presentation time for each output stream.
Wiring guidelines

Ethernet Cat5e cable has a maximum transmission length of 100 meters (328 feet).
DO NOT use media extenders, as they can add an insurmountable amount of latency.
If using fiber optic cable, the same caution applies. There are Small Form-factor Pluggable (SFP) modules that work well with AVB and TSN, and some that do not work at all.
Meyer Sound Galileo GALAXY and NADIA processors include two AVB ports, labeled AVB 1 and AVB 2.
When connecting these devices to a system with only one primary AVB network, always connect to network port AVB 1.
When deploying a redundant AVB network (see the section on Milan redundancy), make all primary network connections to port AVB 1 and all secondary network connections to port AVB 2.
Calculate bandwidth reservation

A key feature of AVB is bandwidth reservation. Bandwidth is reserved for the AVB traffic, which is part of how latency is made consistent and deterministic. The default bandwidth reservation for AVB is 75% of the network bandwidth, which can be adjusted up or down if the network design requires a different value. While the bandwidth is reserved, if it is not being used by AVB, it is still available for “best effort” Ethernet traffic. Without bandwidth reservation, network designers often “over-provision” the network capability because usage can be hard to predict without it.
Good network design is still required, and calculating the bandwidth required for each hop is recommended. Here are some examples to show the scale of the traffic that can be carried on a Milan network:
A 1GigE link with the default 75% bandwidth reservation can transport 200 channels of 96 kHz/32-bit audio using 25, 8-channel streams.
If the sample rate is reduced to 48 kHz and the bit rate is reduced to 24-bit, the same link can transport 440 channels using 55, 8-channel streams.
Estimate bandwidth requirements

Network hardware (switches, cabling) should be compared against estimated bandwidth requirements to ensure the necessary infrastructure is available. There are many resources for calculating network bandwidth, including the online calculator available at https://abc.statusbar.com.
For bandwidth calculators, these AVB stream format details for Galileo GALAXY processors are needed:
Milan AVB AAF format
8 channels per stream
32 AAF samples per frame
AAF sample rate of 96 kHz, and assuming a network with:
1Gigabit Ethernet
75% guaranteed bandwidth available for AVB data,
Use Nebra to maintain persistent connections

AVB listeners maintain persistent connections if they are made using Nebra control software. Connections made with third-party controllers may not be persistent.
Milan AVB connections are made using group names and entity names. If one of the names is changed, it will “break” the connection, and a new connection must be made. Milan AVB connections persist between power cycles.
Galileo GALAXY Snapshots include AVB connections—any AVB connections stored with the Snapshot will be recalled with the Snapshot.
Note
Each Meyer Sound Galileo GALAXY processor includes an AVDECC controller.
Use caution when adding devices to existing networks
![]() |
Caution
Connecting a network switch or another Milan AVB device to an existing network can result in the gPTP Grandmaster changing, depending on preference settings. If that happens, timing on the network may shift, causing a temporary degradation of audio quality while all devices realign to the new Grandmaster.
Milan AVB resources
![]() |
For more information and further understanding of Milan AVB, see the following resources:
References for further reading
![]() |
Audio Engineering Society (AES) recommended practice for digital audio engineering—synchronization of digital audio equipment in studio operations | |
AES recommended practice for digital audio engineering—synchronization of digital audio equipment in studio operations | |
IEEE standard for local and metropolitan area networks—bridges and bridged networks | |
IEEE standard for device discovery, connection management, and control protocol for IEEE 1722 devices | |
IEEE standard for a transport protocol for time-sensitive applications in bridged local area networks | |
IEEE standard for local and metropolitan area networks—timing and synchronization for time-sensitive applications | |
Avnu Professional Audio Functional and Interoperability Specification |
IEEE working groups
![]() |
IEEE 1722 - Transport Working Group — Transport protocol for time-sensitive applications in bridged Local Area Networks (LANs)
IEEE 1722.1 - Management Working Group — AVB/TSN discovery enumeration, connection management and control
Meyer Sound website links
![]() |
Glossary - Milan AVB
- 1722
IEEE 1722 is the standard for transporting audio, video, and control over a time-sensitive network.
- 1722.1
An IEEE standard that enables interoperability between systems that stream time-sensitive media and data across local area networks which provide time synchronization and latency/bandwidth services. The standard specifies the protocol, device discovery, connection management, and device control procedures used to facilitate interoperability between systems that use IEEE 802 time-sensitive networking standards.
- Advanced Authoring Format (AAF)
AAF is a technology specifically designed for digital nonlinear post-production and authoring, which in this case addresses the challenge of multi-vendor, cross-platform interoperability in computer-based digital video and audio production. It is defined in the AVTP standard.
- Asynchronous Sample Rate Converter (ASRC)
An ASRC performs interpolation to fill in missing intermediate values, correcting small deviations between the clock frequencies of digital devices on a network that can cause occasional glitches.
- Audio Video Bridging (AVB)
AVB is the common name for a set of technical standards that provide improved synchronization, low latency, and reliability for switched Ethernet networks. AVB is now often referred to as AVB/TSN or simply TSN (Time-Sensitive Networking).
- Audio Video Discovery, Enumeration, Connection management, and Control (ATDECC)
ATDECC is a system control protocol used for device discovery, connection management, and enumeration and control of parameters defined by IEEE 1722.
- Audio Video Transport Protocol (AVTP)
AVTP transmits the respective data in its payload area, as defined by IEEE 1722.
- AVB channel
The container for an audio signal within a stream. AVB streams carry hundreds of channels. Milan AVB defines required channel counts that must be supported for interoperability between Milan devices.
- AVB components
AVB is defined by these components:
Stream Reservation Protocol (SRP)
Forwarding and Queuing for Time-Sensitive Streams (FQTSS), or traffic shaping
Generalized Precision Time Protocol (gPTP), or time synchronization
Audio Video Discovery, Enumeration, Connection Management (AVDECC)
Audio Video Transport Protocol (AVTP)
- AVB controller
AVB controllers manage AVB networks. Routing, clock selection, and other features relevant to the AVB network can be controlled using these devices. An AVB controller can be software running on a computer connected to the AVB network, but it can also be built into the hardware of an AVB device. A Meyer Sound GALAXY processor is an example of an AVB device with a built-in controller.
- AVB devices
There are four types of AVB devices:
AVB controller
AVB switch
AVB talker
AVB listener
Note
Certain AVB devices can function as more than one type.
- AVB listener
A device that is capable of receiving AVB streams from an AVB talker. All available streams from all available AVB talkers on the network are selectable by the AVB listener as inputs.
- AVB Sink
AVB sink is another name for an AVB listener.
- AVB source
AVB source is another name for an AVB talker.
- AVB stream
A unidirectional flow of AVTP frames with the same unique stream ID. AVB streams can vary in format, channel count, and other parameters.
- AVB talker
A device that is an AVB source capable of transmitting AVB streams. This device will send AVB streams to AVB listeners. When an AVB talker is on the network, it advertises its presence and the streams or channels it is capable of transmitting.
- Avnu Alliance
The Avnu Alliance is a manufacturer consortium that creates an interoperable ecosystem, serving the precise timing and low-latency requirements of diverse applications using open standards through certification. Visit avnu.org for more details.
- AVTP Audio Format (AAF)
AAF AVTP Audio Format, as defined in AVTP, clause 7.
- Best Master Clock Algorithm (BMCA)
The BMCA is a crucial component of gPTP. It automatically determines which clock in the network is the most suitable to be the Grandmaster, considering factors like clock accuracy, stability, and priority. (For some devices, priority can be user-defined to influence the election of the gPTP Grandmaster.)
- Channel name
Channel names identify a specific channel within an AVB stream.
- Clock Reference Format (CRF)
CRF is a format that only contains clock information, not audio. It can be used in AVB audio endpoints, along with the AM824 Stream Format or the AVTP Audio Format (AAF). CRF streams are a low-overhead way to distribute a "house clock" to AVB participants, allowing them to synchronize their media clocks before media streams are established. CRF streams contain clock edge timestamps that have occurred since the last CRF frame was transmitted, which gives them a lower transmit rate than standard media transport streams.
- Forwarding and Queuing for Time-Sensitive Streams, (FQTSS)
FQTSS defines traffic shaping using priority classes, as defined by IEEE 802.1Q.
- Generalized Precision Time Protocol (gPTP)
gPTP precisely synchronizes distributed systems in time-critical applications. This is done through the high-precision, fast synchronization of the timers of all network participants in a distributed system as defined by IEE 801.1AS.
- gPTP Grandmaster Clock (GM)
The gPTP Grandmaster Clock (GM) is the primary time source for a network, acting as the root of the synchronization hierarchy. It distributes time information to all other nodes in the gPTP domain, enabling precise time synchronization across the network. The Grandmaster is selected by the Best Master Clock Algorithm (BMCA) among all available clocks in the network.>
- Group name
Associates multiple AVB devices connected to the same network.
- Institute of Electrical and Electronics Engineers (IEEE)
The IEEE (pronounced "I-triple-E") produces technical standards, organizes conferences, publishes scientific journals, and provides certifications. The IEEE creates the standards that make technologies work together.
Notable IEEE network standards include:
IEEE 802.3 — Ethernet (how computers connect on networks)
IEEE 802.11 — Wi-Fi
IEEE 802.1 — AVB and TSN
IEEE 754 — How computers handle floating-point numbers (important for math calculations)
- Media clock
A media clock is used to control the rate at which the media data is passed to or from the digital converter. For example, the GALAXY processor uses a 96 kHz media clock for audio signals. To keep all media inputs and outputs aligned in time, they need to reference the same media clock. Milan Endpoints can lock to an internal clock reference, recover the media clock from a received AVB stream, or lock to a CRF stream. A Listener must be set to use the same media clock as the Talker. Milan-certified devices use a 48 kHz CRF stream to transport the media clock stream, ensuring that the higher sample rates (96 kHz and 192 kHz) will correctly align with each other. This is independent of the sample rate of the audio stream.
- Milan
Deterministic network protocol for professional audio/visual media with specification and certification led by the Avnu Alliance
- MSRP Accumulated Latency
The maximum amount of time it will take a signal to pass from the AVB talker to the AVB listener. This value is calculated when the stream reservation value is propagated from the AVB talker to the AVB listener.
- Multiple Stream Reservation Protocol (MSRP)
MSRP provides a mechanism for endpoints to reserve network resources guaranteeing the sending and receiving of data streams across a network with the requested QoS. MSRP is one of the core protocols required on an AVB device (talker, listener, and switches).
- Multiple VLAN Reservation Protocol (MVRP)
MVRP is a standards-based Layer 2 network protocol for automatic configuration of VLAN information on switches. Within a layer 2 network, MVRP provides a method to dynamically share VLAN information and configure the needed VLANs. AVB automatically uses MSRP to set up the necessary stream reservations as the user makes connections.
In practice, the necessary VLANs for successful transport of AVB data are automatically configured by the AVB switch (which can also configure non-AVB devices). Users do not have to manually configure VLANs for the successful transport of AVB data.
Note
Only network switches that have been Avnu-certified should be considered when designing or operating AVB networks. The latest list of Avnu-certified hardware, including network switches, can be found on the Avnu Alliance website: https://www.avnu.org/certified-products/.
AVB switch configures AVB and non-AVB devices
- Persistent connection
Persistent connection refers to a connection between Milan AVB devices (a talker and a listener) that remains established even if the network path is temporarily disrupted. This means that if a cable is unplugged, a switch is powered off, or an endpoint goes offline, the connection will be automatically reestablished once the interruption is resolved, without the need for manual reconfiguration.
- Presentation time
Presentation time (also referred to as presentation time offset) ensures that audio data arrives at the listener device within the allocated time, preventing dropouts or synchronization issues. Meyer Sound Milan AVB systems use a default presentation time offset of 2ms, which is generally sufficient for most networks. This default can be adjusted, allowing for lower latency settings; however, network instability and audible dropouts can occur if the setting is set too low. The minimum presentation time offset depends on the number of switch hops and link speeds - the more switch hops, the longer the minimum presentation time offset.
- Protocol Data Unit (PDU)
A PDU is a single unit of information transmitted among entities of a network.
- Rapid Spanning Tree Protocol (RSTP)
RSTP is a network protocol used to prevent loops in Ethernet networks introduced as part of the IEEE 802.1w standard in 2001 and is now widely used in modern networks due to its ability to quickly respond to changes in network topology.
- Sink
An AVB listener has at least one sink, a virtual input. Each sink can receive one AVB stream.
- Small Form-factor Pluggable (SFP)
SFP modules are compact, hot-swappable transceivers used in networking equipment to convert electrical signals into optical signals and vice versa. They facilitate communication between network devices, particularly for gigabit and 10-gigabit Ethernet, Fiber Channel, and other standards. SFP modules are designed for versatility, allowing different types of connections (copper or fiber optic) to be used in the same physical port.
- Source
An AVB talker has at least one source: a virtual output. Each source makes one AVB stream available on the network.
- Stream format
A transport protocol for time-sensitive applications in Bridged Local Area Networks.
The combination of samples per frame, channels per frame, sample rate, and bit depth of a data stream, which is specified in the IEEE 1722 standard.
- Stream Reservation Protocol (SRP)
SRP registers a stream and reserves the resources required through the entire path taken by the stream, as defined by IEEE 802.1Q.
- Time-Sensitive Networking (TSN)
TSN is a set of standards created by the Institute of Electrical and Electronics Engineers (IEEE) to enable traditional Ethernet networks to be used in deterministic, safety-critical applications.