Skip to main content

Meyer Sound Documentation

User Guide — Managing AVB Networks

In this section:
AVB_cover_March_2021.jpg
AVB and Milan Overview
meyer-blue-rule-line.png

The scope of this document is to provide a high-level guide for designing and managing AVB networks using Meyer Sound products. It describes an overview of AVB protocols, the Milan profile definitions, AVB device terminology and Meyer Sound AVB device definitions in particular, network topologies, and general best practices to help system operators get the best possible performance from their system.

This document is not meant to replace information in the IEEE or Avnu specifications. For those documents, see Resources.

Operation and control information for specific Meyer Sound devices can be found on this website (docs.meyersound.com) and in the instructional videos at meyersound.com/videos.

Audio Video Bridging (AVB) is a subset of Time-Sensitive Networking (TSN), both of which are terms specified in a collection of IEEE standards written to facilitate the transport of high-performance audio, video, and control on an Ethernet Local Area Network (LAN). This family of standards specifies how to distribute control and multi-channel signals via a single network connection between devices. AVB is based on open-source standards that are not owned or licensed by any one entity, ensuring its long-term viability. Meyer Sound has integrated AVB into product designs as the preferred choice for distributing digital audio signals and control.

Note

AVB/TSN Standards specify additional capabilities to the Ethernet network to ensure media transportation with low latency and deterministic delivery between devices. 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 network bandwidth necessary along the complete path from AVB talker to AVB listener.

  • Queuing and forwarding rules ensure that such a stream will pass through the network within the time specified by the reservation.

AVB key components
meyer-blue-rule-line.png

AVB is defined by these key components:

Stream Reservation Protocol (SRP)
meyer-blue-rule-line.png

Stream Reservation Protocol (SRP) is part of a standard (IEEE 802.1Q-2018) that specifies the end-to-end management of resource reservations for data streams requiring guaranteed Quality of Service (QoS) in Local Area Networks (LANs). The protocol allows stream endpoints to register their ability to send or receive specific streams and specifies how that information propagates through the network. SRP encompasses Multiple VLAN Reservation Protocol (MVRP) and Multiple Stream Reservation Protocol (MSRP).

Multiple VLAN Reservation Protocol (MVRP)
meyer-blue-rule-line.png

Multiple VLAN Reservation Protocol (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 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_Fig_1.ai

AVB switch configures AVB and non-AVB devices

Multiple Stream Reservation Protocol (MSRP)
meyer-blue-rule-line.png

Multiple Stream Reservation Protocol (MSRP) is a signaling protocol that allows nodes communicating on a network to reserve network resources and ensure an adequate quality of service level to communicate data packets. For time-sensitive data, such as audio and video content, this protocol guarantees that the necessary bandwidth is available and prioritizes its transmission over other network traffic. AVB automatically uses MSRP to set up the necessary stream reservations as the user makes connections.

To initiate a transfer, AVB devices capable of transmitting AVB streams, or talkers, will advertise their available AVB streams on the network. AVB devices capable of receiving AVB streams, or listeners, will respond over the network that they are available. Once a connection is made between a talker and listener, MSRP will ensure the required bandwidth is available to successfully transport the stream from the talker to the listener. An end-to-end signaling mechanism to detect the success or failure of the effort is also provided.

msrp-bandwidth.png

MSRP ensures necessary bandwidth is available

Forwarding and Queuing for Time-Sensitive Streams (FQTSS)
meyer-blue-rule-line.png

Forwarding and Queuing for Time-Sensitive Streams (FQTSS) refers to the need to provide proper pacing of time-sensitive stream data through a switched network in the presence of other traffic. IEEE 801.1Q-2018 specifies how to forward and queue time-sensitive streams so that AVB data has priority, ensuring drops that would cause audible or visible effects do not occur. The result of this traffic shaping is to limit delay and buffering requirements along a stream’s network path.

Generalized Precision Time Protocol (gPTP)
meyer-blue-rule-line.png

AVB devices periodically exchange timing information that allows both ends of the link to synchronize their time-based reference clock very precisely. In AVB networks, this time synchronization is standardized in IEEE 802.1AS-2020. All network switches between AVB endpoints in an AVB network must support gPTP. This protocol implements actions such as:

  • Determining which network links are eligible

  • Electing a grandmaster clock

  • Determining network delay between peers

  • Time-of-day and frequency offsets between the grandmaster and others

The precise time synchronization resulting from the above actions (plus more) between interconnected devices has two purposes:

  • Allows synchronization of data streams

  • Provides a common time base for sampling/receiving data streams at a source device and presenting those streams at the destination device with the same relative timing.

The use for gPTP in professional audio/visual systems is to provide a timing reference for recovery of media clocks in listener devices (see AVB listener) and to provide synchronous media delivery across multiple listener devices. All talker devices (see AVB talker) must also act as listener devices so that multiple talkers can by synchronized based on listening to a common media clock stream referenced to the gPTP timebase.

Audio Video Discovery, Enumeration, Connection management and Control (AVDECC)
meyer-blue-rule-line.png

Audio Video Discovery, Enumeration, Connection Management and Control Protocol (AVDECC) is defined by the IEEE 1722.1-2013 standard. AVDECC is how AVB devices are discovered on the network. AVDECC determines what control points are available, how they are connected, and how the controls are adjusted.

Audio Video Transport Protocol (AVTP)
meyer-blue-rule-line.png

Audio Video Transport Protocol (AVTP) , defined by IEEE 1722-2016, specifies details for transmitting audio/visual data streams including media formats, synchronization and multicast address assignment.

AVB devices
meyer-blue-rule-line.png

There are four types of AVB devices:

Note

Certain AVB devices can function as more than one type.

AVB controller
meyer-blue-rule-line.png

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 switch
meyer-blue-rule-line.png

An AVB switch is a network switch that supports all of the IEEE standards that are required for support of AVB/TSN functions. Initially, there were only a few managed switches that supported the required standards. As the advantages of the various standards become obvious, additional managed switches are supporting more of the standards. A simple way of ensuring that a switch supports all required functions is to use a network switch that has been certified to be AVB compliant by the Avnu Alliance. The latest list of Avnu-certified hardware, including network switches, can be found on the Avnu Alliance website: https://avnu.org/certified-products/.

AVB talker
meyer-blue-rule-line.png

An AVB talker is an AVB source device capable of transmitting AVB streams. The AVB talker will send AVB streams to an AVB listener. When a talker is on the network, it automatically advertises its presence and the streams it can transmit. Use an AVB controller to establish an AVB connection between an AVB talker and AVB listener.

AVB listener
meyer-blue-rule-line.png

An AVB listener is an AVB destination device capable of receiving AVB streams. The AVB listener will receive AVB streams from an AVB talker. All available streams from all available talkers on the network will be visible to the listener automatically. Use an AVB controller to establish an AVB connection between an AVB talker and AVB listener.

Source
meyer-blue-rule-line.png

An AVB talker has at least one source; a virtual output. Each source makes one AVB stream available on the network.

Sink
meyer-blue-rule-line.png

An AVB listener has at least one sink: a virtual input. Each sink can receive one AVB stream.

Milan
meyer-blue-rule-line.png

Milan can be thought of as a “profile” of the AVB/TSN standards. Because of the large number of options that AVB/TSN specifies, it made implementing AVB for live professional A/V applications challenging for manufacturers. Milan was developed to specify what choices were most logical for live sound and video applications where reliability, latency, and fidelity were paramount. Milan offers specifications, developed in collaboration between leading manufacturers in the professional AV industry, to ensure interoperability. The Milan effort takes place under the umbrella of the Avnu Alliance and uses the AVB/TSN IEEE standards.

Milan guarantees the interoperability of pro audio network devices by standardizing the implementation of AVB technology. Standardization means every certified device will discover, talk, and work properly with every other certified device. It means audio networks will enjoy plug-and-play functionality without the need for complex or custom network configurations. All of the existing benefits of AVB are maintained, while Milan opens the door for future growth and development.

Milan defines a set of technical profiles including:

  • Audio stream format

  • Media clocking

  • Redundancy

  • Device discovery and control

Audio stream format
meyer-blue-rule-line.png

Milan requires the AVTP Audio Format (AAF) and support for stream channel counts of 1, 2, 4, 6, and 8. While a device may support other formats, Milan has standardized on these as required settings to ensure interoperability between Milan devices.

Milan-compliant audio stream format

Data Encapsulation

PCM

Format

AAF

Packet Bit Depth

32

Audio Bit Depth

24

Number of Channels

1,2,4,6,8

Sample Rate

48 kHz, 96 kHz

Samples per PDU (Protocol Data Unit)

6 (48 kHz), 12 (96 kHz)

Any Milan device must be compatible with the specifications listed in the table above. AVB talkers can transmit audio streams that contain any of the channel counts or sample rates specified. AVB listeners must be capable of receiving audio streams that use these channel counts and at least one of the listed sample rates.

Media clocking
meyer-blue-rule-line.png

By using gPTP, AVB has an accurate time base to use in the transport of both the media and the media clock. Because gPTP is completely independent of the sample rate, the media clock is transported in the same way as the media. This approach supports the use of multiple independent media clocks in an AVB network when required. To conserve bandwidth, media clocks can be transported using a Clock Reference Format (CRF) as specified in IEEE 1722-2016. This allows for efficient distribution of a media clock signal to multiple devices across the network. It is also possible to recover the media clock from the media stream, which is useful when you have a device like a loudspeaker that is only listening to a single channel of audio.

Redundancy
meyer-blue-rule-line.png

Redundancy under the Milan protocol follows the concept of duplicating network infrastructure into two independent networks, each with its own network switches, cabling, and time domain. Milan also defines a mechanism to allow for a seamless transition from one network to the other in the event of a network failure (e.g., a faulty cable or loss of a network switch). In practical terms, this creates true network redundancy with an automatic failover capability that allows for a transition to the secondary network without any pause or drop of audio.

Device discovery and control
meyer-blue-rule-line.png
  • IEEE 1722.1 is the standard for device discovery, connection management, and control of time-sensitive network systems. It defines how you detect AVB/TSN devices on a network, how you get details about what controls a device has available, how you can make connections to and from those devices, and how you can set control values. The standard supports a wide range of methods to support every conceivable application. Milan has defined the subset of commands useful for ProAV applications. These commands provide the following features:

  • Automatic discovery when AVB devices are added to the network and the ability to show when they have been disconnected.

  • Listing of the current configuration of the discovered device, the name and group name, and all of the controls the device maker has made available.

  • Connection and disconnection of AVB streams between devices. (Streams are how groups of audio channels are carried between AVB devices.)

  • Reporting of the status of the network connection at each device.

Standardizing what information and controls are to be present is one of the ways Milan ensures interoperability between devices.

See www.avnu.org/specifications to download or review Milan documentation.

Meyer Sound AVB devices
meyer-blue-rule-line.png

Meyer Sound offers Milan/AVB devices that include controllers, talkers, and listeners. AVB switches that have been Avnu-certified may be found on the Avnu Alliance website: https://avnu.org/certified-products/.

Nebra Control Software (AVB controller)
meyer-blue-rule-line.png

Nebra is Meyer Sound's control software for GALAXY, which includes the user interface to the controller built into those devices. Nebra is capable of routing AVB and clock streams between devices, displaying critical network information, and storing logs that detail significant events taking place on the network.

Nebra provides a graphical user interface to control all the features offered by the GALAXY processor, Milan-certified endpoints, as well as control of other, non-AVB-capable devices.

Galileo GALAXY Network Platform (AVB talker/listener)
meyer-blue-rule-line.png

The Galileo GALAXY Network Platform is a digital signal processor that is an AVB talker, AVB listener, and includes an AVB controller. It can send and receive AVB audio streams and Clock Reference Format (CRF) streams.

Note

CAL Column Array Loudspeaker (AVB listener)
meyer-blue-rule-line.png

CAL is a digitally steerable column loudspeaker that is also an AVB listener capable of receiving AAF audio and CRF clock streams.

Caution

Although CAL does not forward audio streams to other AVB devices, it does bridge gPTP across both of the Ethernet connectors. If you have implemented a redundant network scheme, attaching a CAL to both the primary and the secondary networks will result in both networks having the same gPTP domain. See CAL network behavior.

CAL is Avnu AVB certified, but not Milan certified. It is compatible with and can operate in systems using Meyer Sound devices, such as the GALAXY processor. It can be treated as a Milan device in all ways except that it does not support any Milan redundancy configuration.

Milan-certified AVB endpoint loudspeakers (AVB Listener)
meyer-blue-rule-line.png

Meyer Sound Milan-certified AVB endpoint loudspeakers are AVB Listeners that include a digital input module, Type 3M. This input module can receive one Milan AVB stream via its Ethernet connector and extract one audio channel from the stream. The speed of the connection is 100 Mbps. The input format is Milan AVB, AAF PCM-INT-32, 96 kHz, and the media clock is recovered from the incoming stream. These devices do not support looping.

Note

For specific information on how to use Meyer Sound Compass control software to route audio signal to Meyer Sound Milan-certified AVB endpoint Type 3M input module Loudspeakers, see the Milan AVB Endpoint Quick Start Guide available at meyersound.com/documents and the meyersound.com/product/compass/#support-videos.

image1.jpeg

Meyer Sound Milan Certified Endpoint Loudspeaker (Type 3M Input Module)

These loudspeakers are readily connected, via an Avnu-certified switch, to an AVB network that also includes a Galileo GALAXY processor (or other AVB Talker) and a computer configured with Compass control software.

Network configurations
meyer-blue-rule-line.png

This section covers possible network redundancy schemes and describes behavior specific to Meyer Sound Milan endpoint and CAL loudspeakers.

Network redundancy options
meyer-blue-rule-line.png

GALAXY processors support two kinds of network redundancy: Milan and cable. Milan redundancy, an optional functionality defined in the Milan standard, is a fully redundant network, as shown in the first figure below. cable redundancy, shown in the second figure below, is an additional capability of Meyer Sound GALAXY processors. This configuration is not required or defined by the Milan specification but provides added flexibility to users.

fully-redundant-network.jpg

Fully redundant network—Milan redundancy

cable-redundant-network.png

Cable redundant network — Meyer Sound additional option

Meyer Sound recommends using a Milan redundant topology wherever possible. AVB networks can be configured in a variety of ways; more robust configurations come at the expense of additional hardware; specifically network switches. Recognizing that specific applications may have restrictions in terms of cost or special requirements, alternative topologies are shown in the following pages. It is the responsibility of the system designer to balance the specific requirements against the available resources for any particular application.

Note

  • When connecting third-party devices that might flood the network with multicast streams or non-AAF/ CRF packets to a GALAXY, the connection should be made to port 2, or a switch connected to the secondary network. Connecting these devices to the primary network or GALAXY port 1 could cause unstable network behavior in extreme cases involving many devices (100+) or large amounts of multicast traffic. This practice should be followed when connecting RMServers to the same network to which GALAXY processors are connected.

  • Analog signals can also be used as a backup; with this approach, there will be no automatic failover in the event of a network failure.

Caution

  • In network setups 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 to ensure the network topologies perform as described. If RSTP is not disabled on network switches in networks that are not fully redundant, redundancy and overall network operation may not behave as expected. See the “Galileo GALAXY AVB Extreme Switch Configuration User Guide” (PN 05.230.105.01) available at meyersound.com/documents for instructions on configuring Extreme switches with RSTP disabled.

  • For cable redundancy to work, you must make both connections from each Meyer Sound talker and each Meyer Sound listener.

Milan redundancy
meyer-blue-rule-line.png

The most robust network configuration is a fully redundant network, referred to as Milan redundancy (this optional functionality is defined in the Milan standard). This topology uses two independent networks; each network consists of discrete cabling, network switches, and time domains. Both networks distribute 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.

A control computer running Compass 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 secondary network.

All primary network connections should be made to AVB port 1 on GALAXY processors. All secondary connections should be made to AVB port 2. The figure below shows one possible configuration that demonstrates Milan redundancy.

milan-redundancy-network.jpg

Milan redundancy configuration

Note

Loudspeakers with Milan endpoint input modules are not shown for clarity. When used, they are connected to the network switches. Loudspeaker endpoints capable of redundancy can connect to both networks. Non-redundant endpoint loudspeakers are connected to the primary network.

Primary network only — cable redundancy
meyer-blue-rule-line.png

The primary network only — cable redundancy configuration, is a Meyer Sound feature that is not part of the Milan standard.

This topology uses a single network with redundancy in the cabling paths between the network switches and the Galileo GALAXY AVB Talker and AVB Listener. A control computer running Compass control software is connected to the network. Each AVB port of a GALAXY is connected to the same network switch. Both GALAXY port 1 and port 2 receive the same source data. In the event of an input data failure on port 1, the GALAXY processor automatically switches to port 2 to maintain the signal flow from the source to the endpoints.

All primary network connections should be made to AVB port 1 on GALAXY processors. Redundant connections should be made to AVB port 2. The figure below shows a configuration that demonstrates cable redundancy.

While not as robust as operating dual independent networks, this configuration offers an additional layer of protection beyond simply running one cable from each AVB device.

primary-network-only.jpg

Primary network only — cable redundancy configuration

Caution

Cable redundancy is only supported by Meyer Sound devices at this time. For cable redundancy to work, you must make both connections from each Meyer Sound talker and each Meyer Sound listener.

Primary network-only — no redundancy
meyer-blue-rule-line.png

The primary network only — no redundancy configuration is the simplest and least robust configuration available. Each GALAXY connects to a network switch via AVB port 1. The AVB port 2 is not used. A loss of any single cable, network switch, or AVB entity will result in at least a partial loss of audio or control.

primary-network-only-no-redundancy.jpg

Primary network only configuration

Meyer Sound Milan endpoint loudspeaker network behavior
meyer-blue-rule-line.png

Meyer Sound endpoint loudspeakers with Type 3M input modules have only one Ethernet connection. This single connection brings with it the following restrictions:

  • Redundancy schemes are not possible

  • Looping from the loudspeaker is not possible. However, with AVB, the same stream and channel can be routed to multiple listeners at once

  • A Milan endpoint loudspeaker only subscribes to one AVB stream at a time. Only one channel in that stream is selected at a time.

loudspeaker-network-behavior.jpg

Position of Meyer Sound Milan endpoint loudspeaker in the network

CAL network behavior
meyer-blue-rule-line.png

CAL network behavior is similar to GALAXY but with two significant differences:

  • CAL bridges gPTP between the two Ethernet connectors

  • CAL can receive Milan AVB audio and CRF, but will only forward CRF.

Caution

Do not loop (daisy-chain) the Milan signal from one Ethernet connector to another — this applies to both the CAL loudspeaker and the GALAXY processor.

Because CAL bridges gPTP across its two Ethernet connectors, it is not fully compliant with Milan redundancy, which is why it is not Milan-certified. When a CAL is connected to both the primary and secondary networks, gPTP information will no longer be redundant.

Synchronization of an AVB network is dependent on a stable master clock. If the master clock device changes, it can temporarily degrade the quality of the audio on the network.

The primary and secondary networks use independent time domains. When a CAL is connected to both networks, it bridges them and creates a network with a single gPTP time domain. Instead of having a master clock for each network, one device will serve as the gPTP master clock for both. The master clock device is chosen based on the Best Master Clock (BMC) algorithm. This algorithm first considers which device has the lowest “Priority 1” value, a parameter that is fixed and inherent for a Milan AVB device. If there is a tie, the device with the lowest MAC address will be selected as the master.

CAL network redundancy behaves similarly to GALAXY—a failure of a component of the primary network will result in a seamless transition to the secondary network without any pause or break in audio. However, unlike GALAXY, the clock will become unlocked for a short period (generally several seconds) before automatically locking again. During this period audio will continue to pass, but there may be phase drift until the clock re-locks.

CAL and GALAXY
meyer-blue-rule-line.png
CAL redundancy
meyer-blue-rule-line.png

The figure below shows an example system consisting of a console source, a single GALAXY, and a single CAL. The connections shown here between CAL, GALAXY, and network switches can be expanded to accommodate additional devices. CAL bridges the gPTP information between the two networks.

cal-redundancy.jpg

CAL redundancy configuration

CAL cable redundancy
meyer-blue-rule-line.png

In the configuration shown in the figure below, the network behaves identically to the GALAXY-only example described in Primary network only — cable redundancy. It is not as robust as using separate switches but offers additional reliability compared to using a single network cable between AVB devices and switches. This configuration is a Meyer Sound extension to redundancy and not part of the Milan redundancy specification.

Caution

Cable redundancy is only supported by Meyer Sound devices at this time. For cable redundancy to work, you must have both connections made from each Meyer Sound talker and each Meyer Sound listener.

cal-cable-redundancy.jpg

CAL cable redundancy configuration

CAL primary only — no redundancy
meyer-blue-rule-line.png

The CAL primary-only configuration, as shown in the figure below, is the simplest and least robust, with only a primary network and a single network cable that connects each AVB device to a switch.

cal-primary-only-no-redundancy.jpg

CAL primary-only configuration

Meyer Sound Milan/AVB networking best practices
meyer-blue-rule-line.png

Every application involving the design and operation of networks must be evaluated on a case-by-case basis. Listed below are Meyer Sound best practices applicable to deploying Meyer Sound devices.

Order of operations
meyer-blue-rule-line.png

One of the most helpful techniques to ensure smooth network behavior is to follow a prescribed order of operations when creating and working with an AVB network. More specifically, the order in which devices are powered on, cable connections are made, and devices are manipulated by AVB controllers can affect network behavior. The following is a suggested order of operations to help ensure smooth network behavior.

  1. Make physical network connections before connecting power. Before AVB devices are powered on, all wiring connections should be made, including talkers, listeners, and network switches.

  2. When possible, apply power to all devices at the same time. 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.

  3. Name entities and groups. Entity and group names identify devices and are used as part of the stream/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 Compass control software.

  4. Connect clocks before distributing audio. For GALAXY there are three clock Mode options you may select: Internal, AVB Clock CRF, and AVB Input. Internal is used if the GALAXY is going to be the CRF source. AVB Clock CRF is selected if you are going to lock the GALAXY to a selected CRF source. The media clock can also be recovered from an AVB stream, so you are able to select an AVB input that has been mapped to an AVB stream.

    Route audio: establish audio connections between talkers and listeners. Talkers will automatically advertise their available streams to the network. Use Compass control software to establish the connections between each listener and talker streams and channels, select the listener, and then the talker stream/channel.

  5. Route audio: establish audio connections between Talkers and Listeners. Talkers will automatically advertise their available streams to the network. Use Compass control software to establish the connections between each listener and talker streams and channels, select the listener, and then the talker stream/channel.

When using CRF, first select the source device in the AVB Clock Selection drop-down box for CRF, then Select the System Clock, Clock Mode, and select AVB Clock CRF from the drop-down menu.

If devices are added to an operating network and unexpected behavior results, powering down all AVB devices and following this prescribed order of operations is a good first troubleshooting step.

Note

For Compass support videos, visit meyersound.com/product/compass/#support-videos

Clocking
meyer-blue-rule-line.png

Precise synchronization of audio signals is a necessity for high-quality sound reproduction. Even very slight offsets in time between sound sources can significantly degrade audio quality. An AVB network uses the Generalized Precision Time Protocol (gPTP) to establish a common clock domain. Media clocks are carried across the network as time-sensitive data, the same as the audio streams. This allows multiple media clocks to be used when needed, without interfering with each other.

Generalized Precision Time Protocol (gPTP)

IEEE 802.1AS-2020 defines Generalized Precision Time Protocol (gPTP). gPTP provides a “wall clock” for the entire network, or an absolute time reference that can be used to synchronize media clocks. A master clock is automatically selected using the Best Master Clock Algorithm (BMCA). The device that the BMCA selects as the master is the device deemed to have the most accurate clock on the network. If it determines multiple devices offer equivalent clock precision, it will choose the device with the lowest MAC address.

Every AVB/TSN packet of information transmitted by a talker includes a timestamp. The timestamp represents an objective, absolute time that is not based on any relative relationships. The source of this absolute time is the designated best master clock. This is how gPTP ensures that all digital audio is in sync across all Ethernet switches in the AVB network.

Media clocks
meyer-blue-rule-line.png

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 the audio signals. To keep all media inputs and outputs aligned in time, they need to reference the same media clock. A Milan AVB endpoint can use an internal reference; it can recover the media clock from a received AVB stream, or it can use 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.

Caution

The CRF stream is a compact and efficient way of distributing a media clock. Meyer Sound recommends using it when available to make it easy to ensure that all devices are using the same media clock source and to use less bandwidth on the network.

Distribution of media clocks
meyer-blue-rule-line.png

All devices in an AVB domain that are going to exchange audio must either use the same media clock or use sample rate converters. A media clock source will be a Milan/AVB device that can send an AAF stream or a CRF stream. A GALAXY module can be a media clock source and can send both AAF and CRF streams. All listeners in a system that can receive CRF streams would be set to listen to the same CRF stream from one source. If a listener can not 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.

Caution

Never mix or cascade media clocks. Use the same CRF or AAF stream to provide the media clock to all devices in a system. Even small timing differences between devices can cause audible audio degradation.

Common system clock for multiple interconnected GALAXY processors
meyer-blue-rule-line.png

When connecting multiple GALAXY processors, one common system clock must be used. Clocks should never be daisy-chained. Even small timing differences can cause audible audio degradation. The figures below illustrate some common media clock distribution methods used with multiple GALAXY processors connected on an AVB network.

The first figure below illustrates a case where an analog or asynchronous AES3 input must be sent through several GALAXY processors. While an audio signal may be daisy-chained from one GALAXY to the next, it is worth repeating that the clock must never be daisy-chained. In the case illustrated in the first figure below, GALAXY 1 receives an analog or asynchronous AES3 input, and its system clock should be set to internal to use the device clock. For an AES3 asynchronous signal, the Asynchronous AES3 Sample Rate Converters (ASRC) must be enabled for that input.

Subsequent GALAXY processors (in this case GALAXY 2, 3, 4, and 5) must receive their media clock from the same source (GALAXY 1), which can be accomplished by selecting the CRF clock (Clock Reference Format Packets) from GALAXY 1.

GALAXY_clocking_1.ai

Media clock distribution scheme for GALAXY processors in series--analog or asynchronous AES3 inputs

The figure below illustrates a case where an AES3 signal aligned to a word clock must be sent through several GALAXY. Again, the clock cannot be daisy-chained along with the audio signal. In this case, if GALAXY A (which must be a GALAXY 816-AES3) receives an AES3 input synchronized at its source to a word clock, its system clock should be set to the word clock received from the same source via the BNC connector. In this case, the ASRC must be disabled.

Subsequent GALAXY processors (GALAXY B, C, D and E which can be any GALAXY model) must receive their media clock from the same source (GALAXY A). This configuration is achieved by selecting the CRF (Clock Reference Format) from GALAXY A as the AVB clock selection. The AES ASRC settings for the AES3 inputs on GALAXY B, C, D, and E, need to be disabled. (The ASRC settings are automatically disabled when using AVB inputs.)

GALAXY_clocking_2.ai

Media clock distribution scheme for GALAXY processors in series--synchronous AES3 inputs with word clock

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 are exchanging audio, either a common CRF stream may be used, or the media clock may 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 one 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, but instead, the GALAXY processors can all be set to use the same CRF stream for their system clock > clock mode.

GALAXY_clocking_3.ai

Media clock distribution scheme for GALAXY processors in series--AVB input source

Signal path delays
meyer-blue-rule-line.png

In many systems, the signal path between a talker and multiple listeners will be different. In an Ethernet network, each connection is called a ‘hop.” The transmission of a data packet between a talker and the first switch is a hop. Each transmission of a data packet between switches is a hop. The transmission of a data packet from a switch to a listener is a hop. Passing through a switch will add a tiny amount of processing delay as the data packet is routed between the input and the output port(s). For example, the figure below shows that between the GALAXY talker and the CAL on the left are two hops, whereas the path going from the GALAXY to the CAL on the right will include three hops because there is an additional Ethernet switch in the path. Fortunately, Milan AVB will automatically make adjustments so that all outputs in an AVB domain will be synchronized. This is the purpose of “presentation time.”

AVB_fig_11.ai

Switch hops introduce signal delay

Presentation time
meyer-blue-rule-line.png

Because all AVB devices on a network use a common time reference (gPTP), and the network knows the transmission time between talker and listener, the talker includes a time stamp, set in the future, for when the signal is to be “presented” at the input of the listener—the presentation time. Including a time stamp ensures that signals are reproduced simultaneously at different listeners regardless of the different transmission paths between talkers and listeners. Devices with more switch hops will need more time to receive the signals.

For example, in the figure below, CAL Pair #2 has one more hop than CAL Pair #1, and CAL Pair #3 has one more hop than CAL Pair #2. An AVB controller can provide a report of how long it takes to reach the most distant device. At a 1 GigE network speed, a switch may add 0.00015 ms, so CAL Pair #3 is 0.00030 ms further away in time. There are a few additional sources of delay including the conversions and processing inside each talker and listener. Meyer Sound Compass control software has a stream info function where the MSRP accumulated latency and the presentation time offset of a received stream can be viewed.

Milan AVB defaults to using a presentation time of 2 ms. This is more than enough to allow for around 12 hops at 1 GigE (1000bT) or about 7 hops at 100bT. In applications where signal latency must be reduced to the absolute minimum, the default 2 ms presentation time may be edited to reduce it to a smaller value as long as allowances are made for the transit time through the actual number of switches along with a reasonable pad for processing overhead in the endpoints. Compass control software allows manual adjustment of the AVB Talker stream presentation time for each output stream.

Presentation time is a fundamental property of AVB. While automatic, the ability to adjust presentation time is possible with Meyer Sound and some other AVB devices. The automatic setting of the defaults makes setup and use fast and easy, but there is also the ability to make adjustments when required.

AVB_fig_12.ai

gPTP and presentation time ensure that all outputs will be exactly in sync with each other

Wiring
meyer-blue-rule-line.png
  • Ethernet Cat5e cable has a maximum transmission length of 100 meters (328 feet).

  • Use caution if media extenders or media translators are used. They must be prequalified as most designs use a “store-and-forward” design which will break AVB timing.

  • If using fiber, the same cautions apply. There are SFP modules that do work well with AVB and TSN, but not all do.

  • Meyer Sound GALAXY and NADIA processors, EP2, and MEP. include two AVB ports, labeled 1 and 2. If connecting only a single AVB network, use 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.

  • If cable redundancy is used (see Primary network only — cable redundancy), both AVB ports should be connected to the same switch.

Note

Both the talker and the listener must have both AVB ports connected for cable redundancy to work.

Bandwidth
meyer-blue-rule-line.png

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 value is 75%, but it 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 a couple of 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.

Estimating bandwidth requirements
meyer-blue-rule-line.png

Network hardware should be compared against estimated bandwidth requirements to ensure the necessary infrastructure is available. The easiest way to make these calculations is to use the online calculator available at https://abc.statusbar.com.

For the GALAXY processor which uses:

  • 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,

The bandwidth calculator result, shown below, indicates that it is possible to transport 200 channels of 32 bit/96 kHz audio in each direction.

image164.png

Bandwidth calculator input (left) and output (right)

Persistent connections
meyer-blue-rule-line.png

Connections made between Meyer Sound Milan/AVB Talkers and AVB Listeners will be persistent if they are made using Compass control software or the Meyer Sound AVB controller. Connections made with a third-party controller may not be persistent. When connections are made between talkers and listeners, messages are sent between the selected talker and listener that query each switch in the path to determine if there is sufficient available bandwidth to make a connection. If the bandwidth is not available, the connection will not be made and the user will be informed that the attempt failed. If there is enough available bandwidth, the connection will be made between the Talker and the Listener. If made using a persistent controller, the settings are retained in each device so that if the path is disrupted, (someone unplugs a cable, a switch or endpoint is powered off, etc.), once everything is restored, the connection will automatically be remade and start passing audio.

Milan AVB connections are made using group name and entity name. If one of the names is changed, it will break the connection and a new connection must be made.

GALAXY snapshots preserve any AVB connections—any AVB connections stored with the snapshot will be recalled with the snapshot.

Note

Each Meyer Sound Galileo GALAXY Network Platform has a built-in AVB AVDECC controller.

Caution

CAL Loudspeaker presets do not maintain or store AVB connections. If a new preset is loaded, the AVB connection must be made again.

Adding devices to existing networks
meyer-blue-rule-line.png

When an AVB device is introduced to an existing network with Milan redundancy, there is a possibility that the device will behave as a CAL does—bridging the gPTP information between the two networks. This behavior will not occur if the connection is made to an Avnu Milan-certified device.

Caution

Connecting a network switch to an existing network might result in changing the gPTP grandmaster depending on the settings in the BMCA. If that happens, timing on the network might shift, causing a temporary degradation of audio quality while all devices realign with a new BMC.

Resources
meyer-blue-rule-line.png
References for further reading
meyer-blue-rule-line.png
  • AES11-2009, “AES recommended practice for digital audio engineering—Synchronization of digital audio equipment in studio operations”.

  • IEEE 802.1BA-2011, “IEEE Standard for Local and metropolitan area networks—Audio Video Bridging (AVB) Systems”.

  • IEEE 802.1Q-2018, “IEEE Standard for Local and Metropolitan area networks—Bridges and Bridged Networks”.

  • IEEE 1722.1-2013, “IEEE Standard for Device Discovery, Connection Management, and Control Protocol for IEEE 1722 Based Devices”.

  • IEEE 1722-2016, “IEEE Standard for a Transport Protocol for Time-Sensitive Applications in Bridged Local Area Networks”.

  • IEEE 802.1AS-2020, “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
meyer-blue-rule-line.png
Useful websites
meyer-blue-rule-line.png
Glossary - Milan AVB
Glossary
1722

The IEEE standard for transporting audio, video, and control over a time-sensitive network. IEEE 1722-21016 is the current version.

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 designed specifically for digital nonlinear post-production and authoring and to help address the problem of multi-vendor, cross-platform interoperability for computer-based digital video production digital a/v format. AAF is specified in the AVTP standard.

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 just TSN (Time Sensitive Networking).

Audio Video Discovery, Enumeration, Connection management, and Control (AVDECC)

AVDECC is a system control protocol used for device discovery, connection management, and enumeration and control of parameters defined by IEEE 1722.1-2013).

Audio Video Transport Protocol (AVTP)

AVTP transmits the respective data in its payload area, as defined by IEEE 1722-2016.

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 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/channels it is able to transmit.

Avnu Alliance

The Avnu Alliance is a community creating an interoperable ecosystem servicing 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.

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-2018.

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-2020.

Group name

Associates multiple AVB devices connected to the same network.

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 that will guarantee 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).

Presentation time

Presentation time is the timestamp on an AVB packet that is used by the listener to know when the samples in that packet are to be played. This ensures that signals across the entire network are reproduced at the same time regardless of the number of hops or distance between devices.

Protocol Data Unit (PDU)

A PDU is a single unit of information transmitted among entities of a network.

Sink

An AVB listener has a least one sink; a virtual input. Each sink can receive one AVB stream.

Source

An AVB talker has at least one source; a virtual output. Each source makes one AVB stream available on the network.

Stream format

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-2016 standard; transport protocol for Time-sensitive applications in Bridged Local Area Networks.

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-2018

Time Sensitive Network (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.