Initially, when our project was instituted, I was oblivious of the potential of the audio video bridging (AVB) standard and its applications, as I was mainly involved in the protocol implementation to get the desired outcome. It was only when I started monitoring AVB products and the AVB demonstrations held by companies in this domain that I learned about its significance.
Let us start with a brief introduction to Ethernet AVB, which has evolved from the existing Ethernet standard. This technology ensures tight control over the quality of service required for streaming real-time high-quality audio and video over wired Ethernet. Before the existence of AVB standards, the audio and video set-up involved a large number of cables intertwined with each other. Now, AVB technology provides a high quality audio and video experience using structured wiring without any complicated set-ups, while coexisting with the other non-media network traffic. AVB technology involves fundamental changes to the Ethernet standards to support the audio-video media distribution, by furnishing high precision network synchronisation, dynamic bandwidth reservation to ensure packet delivery within stipulated latency and traffic shaping to minimise bandwidth needs. It also eliminates media bursts even when passing through multiple network hops, and provides admission control to ensure that non-AVB devices dont degrade the performance of the AVB network and devices. The AVB ecosystem is evolving and creating its own niche in the automotive infotainment, consumer electronics, broadcast system design and other domains.
Before the AVB standard came into existence, there was no standard way to synchronise the audio-video devices, to reserve the bandwidth and resources to stream real-time AV data between these devices, and to discover and control them. To understand the functionality of AVB, assume you have listener devices – one speaker in the kitchen, one in the garage and one in your bedroom. You have a talker device, like a mobile, connected with the three speakers in an AVB network, and you wish to stream AV data to these listener devices in real-time. You also want to download data from the Internet, simultaneously, on your mobile device. The real-time streaming will not be affected even when non-AVB traffic faces traffic congestion, and the AV data will be played at the same instant by all the listeners.
AVB is the name given to a set of protocol standards developed by the IEEE Audio Video Bridging Task Group. To standardise and improve the interoperability of AVB devices and networks, a consortium of automotive and consumer electronics companies, called the AVnu Alliance, was formed in August 2009. It constantly strives to establish and certify AVB products which ensure interoperability and improve audio/video quality.
In general, an AVB ecosystem deploys the following protocols:
IEEE 802.1AS: Timing and synchronisation for time-sensitive applications (gPTP)
IEEE 802.1Qav: Forwarding and queuing for timesensitive streams (FQTSS)
IEEE 802.1Qat: Stream reservation protocol (SRP)
IEEE 1722 Layer 2 AVB transport protocol
IEEE 1722.1: Audio video discovery, enumeration, connection management and control protocol (AVDECC)
IEEE 1722.MAAP: MAC address acquisition protocol
How the AVB stack resides in an AVB device can be understood from Figure 1.
The talker and listener set-up forming an AVB network can be understood from Figure 2.
Let me introduce you to the first four basic AVB protocols required to form an AVB network. With these standards, one can have a single talker-listener set-up working in an AVB network. But to establish an AVB network comprising multiple talkers and listeners, one needs to provide the support of the other two (AVDECC and MAAP) standards to manage and control these devices.
IEEE 802.1AS
The IEEE 802.1AS protocol plays a pivotal role in synchronising AVB devices by exchanging timing information over the network. This exchange of timing information allows the AVB devices to synchronise their local clocks with reference to a standard AVB clock.
The model adopted by gPTP is analogous to the slave-master model, where the master exchanges its timing information with the other AVB devices (slaves) and the slaves synchronise their clock with the master (see Figures 3 and 4).
IEEE 802.1Qav
This traffic shaping (queuing and forwarding) protocol is implemented at the hardware layer (MAC). Traffic shaping involves prioritising the transmission of packets to maintain the standard streaming rate required to transfer AVB packets while handling non-AVB network traffic. It can also be termed as bandwidth reservation protocol. To recap, the definition of bandwidth means the number of bits transmitted per unit of time, and the hardware controls the number of packets transmitted per unit of time, using credits.
Let us assume credit to be an X constant value. Now, whenever there is an AVB packet to be transmitted, the hardware checks for the value of X. The credits, i.e., the value of X, keeps getting accumulated at a constant rate when an AVB packet is queued. If the value of X is positive, the AVB packet is transmitted out of the hardware; otherwise (if the value of X is negative), the AVB packet is buffered until the value of X rises again and becomes positive. During this interval, the hardware gets busy dealing with non-AVB traffic, thus handling AVB and non-AVB traffic efficiently.
This is just a short summary of how the hardware reserves bandwidth for AV traffic, to ensure the desired QoS. Refer Figure 5.
IEEE 802.1Qat
The stream reservation protocol ensures the reservation of network resources for specific AV streams traversing bridged networks. It determines the resources required, and exploits a mechanism for dynamic maintenance of those resources.
Before the source starts initiating the AV traffic, it sends the talker advertise message across the network. This message consists of the following: source and destination MAC address, 16-bit unique ID and information about the resource requirements. The bridge receiving this message sets aside or reserves the requested resources, and propagates the message to the next system. The listener responds with a listener ready message, which is sent back to the talker. If any bridge fails to allocate the requested resources, it sends a talker fail message to the other systems, which results in AV traffic streaming getting aborted. This is how a stream is actually registered with the bridges and the two endpoints talker and listener communicate with each other. The resources comprise ensuring port throughput, data rate and registering AVB class. Refer Figure 6 and Figure 7.
IEEE 1722 Layer 2 AVB transport protocol
This protocol basically handles the packetising of the AV data into a standard 1722 Ethernet frame. It also shoulders the responsibility of passing down the 1722 AVB packet to the driver for it to transmit over the Ethernet.
This protocol is implemented as part of the talker application, which does the following:
- Reads raw audio/video data from a file
- Packetises the same data into a standard AVB Ethernet frame
- Delivers the AVB Ethernet frame to the lower layer driver for its transmission
This application has also undergone significant modifications, which involve reading data directly from the AV devices and streaming it to the listener application. The main purpose of this is to extract the raw data and play it in real-time over the loudspeaker/headphones, or when using an ALSA sub-system.
We are currently experimenting with an AVB set-up that involves AVB endpoints (talker/listener) designed and developed by XMOS and an AVB Ethernet switch from DSP4U. Initially, our set-up included only one talker and one listener, with support from the first three AVB protocols, but now the AVB stack has evolved and is mature enough to handle multiple AVB devices in an AVB network. We will discuss the AVDECC, MAAP and IEEE 1722 layer 2 transport protocols in the next article about multiple AVB devices in an AVB network.
But before we do that, heres some food for thought. Can you think of another domain where this technology can penetrate? What will an entire AVB network set up using Ethernet LAN cables look like? Quite clumsy, right! So whats next? An AVB wireless chip?
References
[1] http://en.wikipedia.org/wiki/Audio_Video_Bridging
[2] http://www.ieee802.org/1/pages/avbridges.html
[3] http://blog.meinbergglobal.com/category/ieee1588/
Videos
[1] https://www.youtube.com/watch?v=R8Hjyu4IIkE
[2] http://www.xmos.com/news/videos?search=AVB
[3] https://www.youtube.com/watch?v=kQ7FBbH-krM
