Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×

Audio Video Bridging

Audio Video Bridging

Jul 1, 2012 2:00 AM, By Doug Irwin, CPBE DRB AMD

Digital protocols abound, but is AVB a standard for radio?

If you have worked with AoIP or other digital audio transmission schemes you may have heard the acronym AVB bandied around. Just what is AVB, and how might it come in to play in broadcasting? That’s our topic this time around.

We’re all familiar with the big console/router manufacturer’s systems – whether AoIP- or TDM-based. To a very large degree (although not completely) those systems remain proprietary. Audio Video Bridging (AVB) is the name given to the implementation of four protocols developed by the IEEE. One of the primary purposes behind all the work done was the development of a non-proprietary means by which different manufactures products could communicate with one another over Layer-2 (Ethernet) networks for purposes of media streaming. (The AVnu Alliance is a group of manufacturers that has formed with the express purpose of ensuring interoperability.) Another primary purpose behind AVB is to ensure multiple, related streams can be streamed across a network, with precision synchronization, and very low transit time.

To learn a little more about AVB we’re going to look at its four facets in detail: IEEE 802.1BA Identification of Participating Devices; IEEE 802.1Qat Admission Controls; IEEE 802.1Qav Traffic Shaping for AV Streams; and IEEE 802.1AS Precise Synchronization.

As with any transmission scheme, there is a source and a destination. In the context of AVB the source is known as the talker and the destination is known as the listener. For the benefits of AVB to be realized all the intermediate points must be AVB capable. The intermediate points are ports on a Layer-2 switch that in this context will be known as AVB bridges.

Whether or not an AVB link can be established between a talker and listener is determined during the establishment of the Layer-2 connections – in other words when a port on an AVB bridge is brought up. Four specific (802.1BA) requirements are:

? The link is a full-duplex, 100baseT connection (or faster)
? 802.1AS protocol (which we’ll discuss below) discovers exactly one peer on the port
? The maximum round-trip delay time from the port to the AVB peer meets requirements specified in 802.1AS
? An 802.1Qat “Stream Reservation Protocol” (SRP) request or acknowledgment is received on the port

– continued on page 2

1 2 3 4 Next

Audio Video Bridging

Jul 1, 2012 2:00 AM, By Doug Irwin, CPBE DRB AMD

Digital protocols abound, but is AVB a standard for radio?

Once it’s established that a device is an AVB talker, and that the port used to connect that to the rest of the network is AVB-capable, it’s necessary to know if an AVB listener can be reached. The listener might be on another port on the same AVB bridge (Layer-2 switch) or it might be separated by two (or more) switches. This is where 802.1Qat comes in to play – it’s the process by which the participating devices determine whether or not AVB connections can be made all the way from talker to listener. Stream Reservation Protocol (SRP) is used for this. A talker will send a “talker advertise” message, which includes QoS requirements (we’ll talk about those a little later), a stream ID made up of the talker’s MAC address, a talker-specific 16-bit ID, the MAC address of the listener (which implies that the talker knows all potential listeners before streams are established), and accumulated latency (how long it takes for messages to propagate between the talker and the bridge).

When an AVB bridge receives this advertisement, it checks to see whether or not the necessary requirements for the proposed stream are in fact available. If they are, then the talker advertisement is propagated outbound on the appropriate port. If they are not available, then a ‘talker fail’ message is sent back towards the originator. Included in that message will be a failure code along with an AVB bridge ID that will allow the higher-layer applications (that are using AVB to talk between devices) to know where the issue is.

When a listener receives a talker-advertisement, it is known then that the intermediate points (AVB bridge ports) are ready for the stream to pass through. It will then send an acknowledgment message back towards the talker. As the intermediate bridges receive this message, they reserve the appropriate resources for the passage of this stream by making entries in their forwarding databases. (In other words, as they receive a particular stream, they will guarantee its priority and bandwidth.) When the talker finally receives the message back from the listener, the stream can start up.

While the stream is being sent, both the talker and listener will send periodic messages indicating to the intermediate bridges that the resources are still needed. When they are no longer needed (for whatever reason, the stream has ended) both ends will send a specific de-register message that will allow the intermediate bridges to release the resources. If the bridges don’t hear the periodic messages, they’ll ‘age-out’ the resources themselves.

The benefits

Let’s get in to the advantages that AVB provides: quality of service, and precision timing.

802.1Qav for AVB provides for what I think can best be described as an automatic, dynamic QoS mechanism that is hidden from the end-user. This QoS is ensured by traffic shaping, and admission controls (described above). Traffic shaping is a method by which the frames of the particular stream are regulated in the sense that they are being sent on a smooth basis (as opposed to bunches) very purposefully. Additionally the frames are tagged with a high-priority and as such will receive the necessary consideration from the forwarding database in the AVB bridge. All the best-effort traffic will essentially take a back-seat to the streaming traffic.

In a non-AVB system, the bridges (or Layer-2 switches) would have to be configured and support QoS all the way through the network, and this takes a certain amount of expertise that not everyone has.

– continued on page 3

Previous 1 2 3 4 Next

Audio Video Bridging

Jul 1, 2012 2:00 AM, By Doug Irwin, CPBE DRB AMD

Digital protocols abound, but is AVB a standard for radio?

Traffic shaping is important because it allows for a predictable amount of time for the stream to pass through a system. Think about it: a set of devices that use the public internet for transmission have to make use of a buffer so that they don’t run out of data to convert to the actual stream output, while waiting for packets to arrive from the far end. Since the packets can arrive in bunches, followed by none for a time, the buffer has to be fairly deep.

However, if you can manipulate (or ‘shape’) the traffic so that it comes through consistently, you can make the buffer very short – and you can effectively speed up the time it takes for frames to propagate through the system.

The last aspect of AVB is that of precision timing (802.1AS). This is probably more important in video applications than radio. For example, if you have two streams, one for video, and one for its associated audio, then they have to be synchronized, otherwise anyone watching could notice a lip-sync problem. That’s always annoying. AVB works to solve this problem. In an AVB network, one of the participating devices will become the grandmaster time source. (All other devices will be slaves.) The various devices that make up the AVB network periodically exchange time information. And, as I have mentioned previously, a talker knows how long frames take to propagate from end to end; so by adding that latency information to the frames themselves, along with a time stamp, the listener is able to synchronize the stream outputs by taking in to account the network latency. Differences in time between two associated media streams, caused by propagation delays through different paths, can be mitigated.

Broadcast use

SAS KDL-16

So now that we’ve learned something about AVB, who is using it in our field? SAS offers a module for its 32KD system that allows the user to interface AoIP to the system, making use of the AVB standards. The KDL-16 offers 32 channels in, and 32 channels out of a 32KD network. Obviously, when connected to an AVB-capable LAN, any other device using AVB will have access to the 32KD system.

– continued on page 4

Previous 1 2 3 4 Next

Audio Video Bridging

Jul 1, 2012 2:00 AM, By Doug Irwin, CPBE DRB AMD

Digital protocols abound, but is AVB a standard for radio?

Avid Venue SC48

While Avid is well known for ProTools, is also makes consoles and one particular system makes of use AVB: the Venue SC48. This system is made up of an SC48 digital console, with an AVB interface plug-in, that connects (via Ethernet) to the Venue Stage 48, a large I/O box that allows the system user to place the inputs and outputs of the system close to the performers. Up to 48 inputs and 16 outputs can run between the two ends, over the AVB snake.

Netgear GS724T

But what about the AVB bridges themselves? You have at least a couple of choices: the Netgear GS716T or GS724T, and the Titanium 411, a six-port gigabit Ethernet bridge from LabX.

LabX Titanium 411

AVB is a non-proprietary means by which different audio (and video) devices can communicate with one another, for the purposes of media streaming, over the ubiquitous Ethernet LAN. It’s an implementation of four protocols developed by IEEE, allowing interoperability, and ensuring that multiple, related streams can be streamed across a network, with precision synchronization, and very low transit time, and guaranteed QoS.

Irwin is transmission systems supervisor for Clear Channel NYC and chief engineer of WKTU, New York. Contact him at [email protected].

July 2012

AVB for radio, a tour of WZIP-FM, update on translator rules, and Field Reports on the Inovonics David IV and Audio-Technica AT2005USB…

Previous 1 2 3 4

Close