Meyer Sound Milan/AVB networking best practices
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
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.
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.
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.
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.
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.
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
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
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
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
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.
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.)
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.
Media clock distribution scheme for GALAXY processors in series--AVB input source
Signal path delays
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.”
Switch hops introduce signal delay
Presentation time
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.
gPTP and presentation time ensure that all outputs will be exactly in sync with each other
Wiring
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
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
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:
The bandwidth calculator result, shown below, indicates that it is possible to transport 200 channels of 32 bit/96 kHz audio in each direction.
Bandwidth calculator input (left) and output (right)
Persistent connections
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
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.