Meyer Sound Documentation

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)

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 switch configures AVB and non-AVB devices

Multiple Stream Reservation Protocol (MSRP)

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 ensures necessary bandwidth is available

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.

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:

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

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 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) , defined by IEEE 1722-2016, specifies details for transmitting audio/visual data streams including media formats, synchronization and multicast address assignment.

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

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.

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

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.

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.

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.