There is much chatter, increasing availability, and development of standards related to passing Audio over Networks. This article will share some insights to these developments, the underlying protocols, native macOS functionality, consumer AVB products, and considerations for producers looking to benefit from affordable networked audio solutions.
Confusion about these standards, and their implementation on macOS is natural, resulting from their relative newness, and sets of implementation knowledge that fall outside the typical producer’s workflow and hardware & software setups.
Overview – AOIP – TSN – AVB — What do the Terms Mean?
In the IEEE-1722-2016 Standard for a Transport Protocol for Time=Sensitive Applications in Bridged Local Area Networks, which is the active standard, the differences between AVB and TSN are defined (see image below). It’s important to note from the start, that since AVB’s inception around 2006, several changes have occurred. Between 2006 and Around 2013 the AVB working group had successfully developed and implemented a set of protocols for Audio Video Bridging. The AVB protocols were next to become an aspect of the broader set of protocols related to (TSN) Time Sensitive Networking, which in large part brings Control type messages necessary for Industrial Ethernet applications. While there have been a set of protocols for deterministic control-based Ethernet-working, they require un-shared networks, whereas with TSN, Industrial Ethernet will greatly benefit from both lower deterministic latency, and more inclusive network communications. As such, shortly after 2013 the AVB working group was transformed to the TSN Group. TSN utilizes AVB as a subset of protocols specific to Audio and Video, but also as part of the PTP (Precision Time Protocol), and gPTP(Generalized), which are an impressive way to clock all of the nodes in a spanning tree fashion, which has a Grandmaster Clock to which all clocks are bound. gPTP is used in WAN Transport, and provides an additional clock abstraction along the AVB nodes, allowing time synchronization to be maintained across hops, a notion also known as transparent clocks. macOS since Sierra supports the AVB protocols, though I can’t exactly ascertain to what degree the current TSN standards match with the macOS AVB implementation.
Link to Latest Standard: IEEE Std 1722-2016 (Revision of IEEE Std 1722-2011) – IEEE Standard for a Transport Protocol for Time-Sensitive Applications in Bridged Local Area Networks.
A subgroup of the 1722 Working Group is the 1722.1 Working Group, which has purview over the ATDECC (AVB/TSN Discovery, Enumeration, Connection management and Control)
Now let’s walk back a few steps to see how AVB & TSN come to bear on Audio & Video production. Before getting to AVB & TSN, the more general term AOIP (Audio-Over-IP) can be used to describe any technology utilizing network protocols to transfer audio. This could include, by example, a traditional analog device such as a guitar, whose signal is played out into an Audio Interface, processed through some computer software, and then maybe routed out over a network to its final destination. Or a local are network of computers at your house, configured to pass audio over your home’s switch, or even sharing that audio to another physical location, with guaranteed bandwidth and deterministic latency. Basically the idea is somewhere in your audio chain, audio is passing over the network.
Under the Classification of AOIP fall a variety of AOIP Standards and Protocols. AOIP isn’t a new idea, and there are several well-established platforms. Traditionally, these platforms have been mostly proprietary, generally used in commercial applications such as stadiums, deployments on campuses with multiple buildings, and other locations where the distance limitations nominally exceed the ranges afforded by analog devices. These platforms have been very helpful, facilitating the further development of AOIP technologies, which, coupled with increased bandwidth availability of networks, have brought about newer platforms and technologies, which can afford access to small businesses and home recording studios. These technologies will be the focus as we continue on. Examples could include CobraNet, Ethercon, MADI, Ravenna, Rocknet, and the like. These platforms have traditionally been reserved for larger commercial applications, although there are plenty of modules allowing connections between these platforms on most flagship mixer product lines.
The AVB (Audio Video Bridging) working group was incepted around 2006, with the
I also don’t want to misrepresent these “earlier” technologies as outmoded or legacy, as they are all still in use. But the more recent platforms, standards, and technologies are increasingly practical at the consumer level.
Now for a bit of terminological confusion. Two popular platforms, AVB (Audio Visual Bridging), and Dante from Audinate, overlap a bit in their underlying platform, but are also different.
AVB is a technology baked into macOS. The terminological confusion about AVB, stems from AVB having changed since its inception, such that the term itself has become inaccurate. AVB, as mentioned above, is now a subset of what’s called TSN (Time-Sensitive-Networking). And TSN isn’t a single technology or protocol, it’s comprised of several protocols, of which AVB is a particular subset. These changes, still underway and under very aggressive development, can make it challenging to find accurate details on product lines and technologies. There are also opportunities baked into the AVB/TSN protocols allowing manufacturers to customize their product offerings, which can cause issues when assessing them, as it’s challenging to find out what version of the protocol they’ve implemented, and what aspects of the implementation might adversely affect its interoperability with other AVB/TSN offerings.
So if you’re considering AOIP for your studio, it’s important to pay great attention to the technical specifications of any hardware you’re considering. You’ll need to ensure it will work with your home network, your particular computers, and software. Additionally, considering the platforms themselves in terms of their AOIP offerings, what their commitment to updating their line to ensure interoperability with other AVB products, and mapping to the changes in the various protocols underlying their technologies. While the TSN protocols are generic to technology, there is ample opportunity for an “AVB-compliant” product to have proprietary lock-downs, or to lack elements of a fully compliant product, or to fall out of compliance when the protocols are updated.
So there is no absolute “strict” definition of an AVB-compliant object. One solid reference, though, is the AVNU Alliance – They provide a compliance certification for TSN offerings, which seems oriented toward TSN hardware manufacturers, of network interface devices, rather than consumer-facing products, which is important to the TSN standards having reliable interoperability, which also provides end-users more choices, and generally more open architectures. Equally important though, their website has an excellent selection of technical papers related to the standards, and news related to developments on the TSN front.
If you happen to have academic library access, check if they have a digital subscription to the IEEE database, where you can access the standards themselves. Unfortunately, the standards are otherwise sold at the IEEE website.
IEEE and Developing of TSN-Related Standards
The IEEE TSN Working Group, is one of 5 working groups that fall under the IEE’s 802.1 Working group, which has a broader purview. It’s important to keep in perspective that when a product is labeled AVB/TSN – there are other ancillary network protocols that will affect the operation of the device, as TSN is inherently connected to the the other relevant local and WAN standards. The TSN Task Group, was previously the AVB Working Group, with a move to the new name a few years back. This makes sense as AVB preempted TSN, which, after its formalized inception superseded the scope of AVB, and as such has subsumed AVB protocols to the broader set comprising TSN. All these iterations have taken place only over a decade, and as I mentioned earlier, coming to grips with the particulars of any AVB-TSN product, is challenging.
- IEEE Std 802.1Qbu-2016 – IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks — Amendment 26: Frame Preemption. It allows a Bridge Port to suspend the transmission of non time critical frames while one or more time critical frames are transmitted. It is being rolled into 802.1Q by the ongoing P802.1Q-REV project.
- IEEE Std 802.1Qbv-2015 – IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks — Amendment 25: Enhancements for Scheduled Traffic. It specifies time aware queue draining to schedule the transmission of frames relative to a known time scale. It is being rolled into 802.1Q by the ongoing P802.1Q-REV project.
- IEEE Std 802.1Qca-2015 – IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks — Amendment 24: Path Control and Reservation. It extends the application of Intermediate System to Intermediate System (IS-IS) to bridged networks in order to provide explicit trees for data traffic. It is being rolled into 802.1Q by the ongoing P802.1Q-REV project.
- IEEE Std 802.1AS-2011 – IEEE Standard for Local and Metropolitan Area Networks — Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks. It provides a Layer 2 time synchronizing service that is appropriate for the most stringent requirements of consumer electronics applications. This was done in cooperation with the IEEE 1588 working group, and so the point-to-point 802.3 sublayer of 802.1AS is a specific profile of IEEE Std 1588-2008. IEEE Std 802.1AS specifies the generalized Precision Time Protocol (gPTP). See also IEEE 802.1AS-2011/Cor1-2013 and IEEE 802.1AS-2011/Cor1-2015. Note the ongoing P802.1AS-REV project.
- IEEE Std 802.1Qat-2010 – IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks – Amendment 14: Stream Reservation Protocol (SRP), which has been rolled into IEEE Std 802.1Q-2014. Note the ongoing P802.1Qcc project, which specifies enhancements to SRP.
- IEEE Std 802.1Qav-2009 – IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks – Amendment 12: Forwarding and Queueing Enhancements for Time-Sensitive Streams, which specifies the Credit Based Shaper. It has been rolled into IEEE Std 802.1Q-2014.
- IEEE Std 802.1BA-2009 – IEEE Standard for Local and Metropolitan Area Networks — Audio Video Bridging (AVB) Systems. It specifies a set of usage-specific profiles to help interoperability between networked devices using the AVB specifications.
How to Monitor TSN Traffic on Your Network
You can utilize Wireshark to monitor IEEE 1722 traffic. This has come in quite handy for me, as most product documentation doesn’t go into the specifics of their AVB implementations. Nevertheless, the AVB protocols, while allowing flexibility, must contain the properly formatted AVB packets, such that they can be read along the AVB network they traverse. Wireshark can isolate packets to the 1722 traffic, for example, so you can quickly capture that traffic and find out what sorts of information your AVB devices are handling. Here’s a screen capture of some TSN packet descriptions:
Wireshark also has a terrific list of all the specific types of packets specific to the IEEE 1722 protocol. Wireshark is utilized by people who really really care about packet structure, and as such, it even keeps track of any changes to packet structures over time as standards change, which is very helpful if you’re using an implementation that isn’t updated, or even utilizes an older version’s packet structures: Here’s the full List of Packet Types for IEEE 1722. I’ve done a bit of capturing, so here’s a few screen grabs of some TSN packet captures from Wireshark:
TSN Prioritization Classifications – Class A vs Class B for WAN communications
I should also note there are several differences in how TSN traffic is handled, depending if your TSN is local, or WAN-based. Sending TSN traffic out across the internet requires some additional fields, to properly synchronize, and to be prioritized across the WAN. TSN WAN traffic can be Class A (Higher Priority), or Class B, depending on characteristics such as number of Audio Streams and Channels, and the PDelay timer settings, by example. So if you’re working in a WAN-based TSN deployment, it’s important to note the Latency guarantees are quite different between Class A & B traffic. On a LAN-based TSN deployment, Latency should be bound to sub 2ms with up to 7 Hops. Note that a TSN requires all devices within its boundaries to be TSN-compliant. So you can’t plug in a Switch to an AVB-Switch, and expect to have AVB capabilities on the non-AVB switch.
Features of TSN for Music & Video Producers
Easily one of the best features of TSN is the available bandwidth. On a Standard Gigabit Switch, it’s no sweat to have 64 or more channels of lossless bi-directional Audio, all synchronized under 2ms. Also, any devices plugged into your Network, can send and receive their audio to any other network location. This affords a Virtualized Patchbay, allowing the distribution of Plugins across computers, for example, networking several computers together can ease the processing on each computer, and with deterministic latency, route their processed audio to the next stop. Inexpensive Cat5e can be ran up to about 100m’ – allowing you to cable up devices in different rooms, without all the headwind of cabling costs and distance limitations of analog and USB protocols.
Configuring AVB on macOS
In this section I’m going to show how to configure AVB for macOS, and as I’ve only had an TSN-enabled switch for a week, I’ll share some of my current confusion as well. Thus far, I’ve not come across much documentation on the AVB/TSN capabilities of macOS. As many of you have noticed, in Audio MIDI Setup you can Click Window–>Show Network Device Browser (CMD+3). Here’s what my MacBook Pro shows:
As you can see, my MacBook Pro is listed as an AVB Device, with the Speaker icon under the Capabilities tab indicating it’s an AVB Audio Device (MIDI & Video are also possible). If you’ve purchased an AVB device, it should list here as well. Similar to macOS Audio Devices, AVB Audio Devices can be customized by their developers. Apple as well, I suppose, might also do the same. I’ve not yet found definitive resources indicating the specific versions of the underlying protocols, amongst other challenges…
Before getting into the details of configuring the Mac as an AVB Audio Device, it’s prudent to note some of the commercial offerings of AVB, or AOIP-based interfaces and network switches. There are now solid and reasonably consumer priced audio interfaces and switches, offering the high channel counts and deterministic latency the protocols bring, reduced cabling requirements, and flexible patching these systems afford. Let’s take a look at a few below.
Some Good Options for incorporating Networked Audio to your Studio:
MOTU AVB Switch – MOTU has probably the strongest AVB/TSN offering at the Prosumer level. Along with their AVB Switch, they have a line of AVB/TSN audio interfaces, with various configurations of AVB/TSN, USB & Thunderbolt, and I/O options.
Presonus also offers an AVB Switch the SW5E, along with several AOIP modules for their Studio Live mixers.
The DigiGrid Line, featured on Waves’ website, is also affordable, with small desktop interfaces with different I/O options, including Ethernet connectivity to their SoundGrid Studio – which is an AOIP-based patchbay. Waves also offers their Impact Servers, which are hardware dedicated to running Waves Plugins, allowing you to route network audio through Waves plugins, offloading that processing to the Impact server. And just recently announced is the WSG (Waves Sound Grid)Bridge for Dante, which will be useful for those running WSG & who want to further bridge that Audio to the broader Dante network.
Focusrite’s RedNet line is well-established in the professional networked audio arena, but they’ve also recently announced an interface – the X2P, to the RedNet Line, an affordable 2×2 Analogue I/O Interface With 2x Mic Pres, Headphone And Line Output, PoE Supplied, which is a Dante interface, and is showing Preorder price of $899.99.
Given the range of AOIP-centric audio interfaces in these price ranges offered by well-known providers, they are certainly a good option for everyday studios, given the bandwidth afforded by our home networks and computers. The switch market is also reasonably priced now, with gigabit unmanaged switches like the Netgear GS716TV3, coming in under $200 and with an option EAV license, enables the 802.1AS functionality for TSN compliance. The Netgear GS724TV4 (the switch I settled on), and the Netgear GS748TV5 are also TSN-able with the optional EAV license activated.
Similar protocols like Dante, have well over 1000 products certified for their AOIP protocol, and seems to have supplanted the extant AOIP protocols to some extent, though there will be inevitably quite a few legacy installations requiring ongoing support, and modules to connect these newer protocols. Dante just this past fall unveiled DDM, Dante Domain Manger, which offers tiered licensing for creating Dante Domains, similar to TSN’s broadening of AVB to a deterministic spanning tree of clocks, Dante’s Domain Manager offers tiered licenses for a Dante Domain Network of 2 or more Domains, each guaranteeing performance standards which are key to the Audio community, and overlap in focus with the TSN-related standards.
Audinate also made a very exciting announcement on the eve of 2018’s NAMM, of their AVIO line of adapters. These adapters allow you to, for example, plug in the adapter to your analog speakers with XLR, and then plug out the adapter directly to your switch. Now your analog speaker shows up on your Dante Network as a Receiver, and you can send Networked Audio from any source(s) to that speaker. Another Adapter does the same, but for USB Devices, again making them available on your Dante Network, with deterministic low latency, and the ability to interact with those devices from any available “listener” on the Dante Network.
These adapters will enable all manner of synthesizers, control surfaces, analog mixers, speakers and the like to become networked audio devices. Distance limitations also increase, as 100M is the limit, still a much greater distance than practically possible with analog or USB cabling. Dante also works with Switches that have SFP ports, so fiber optic cable runs are also possible, extending the distance limitations to 1 or 2 kilometers, with multimode, and single mode fiber runs.
While this article is focused on using native macOS AVB, I should note that Dante is what I use on a day-to-day basis for networked audio. Dante Via, DVS, and Controller combine to make an excellent software based networked audio system, between Mac’s and/or Pc’s. Here are some views of the software interfaces for the Dante platform:
Prerequisites for Enumeration of your macOS computer as an AVB Audio Device
Having looked at some of the AVB/TSN offerings and platforms, let’s draw back to the AVB functionality build in to macOS, with the goal of utilizing 1 or more Mac’s, and/or PC’s as AVB Audio devices, and to evaluate the available channel counts, latency measurements, and general performance of the built in AVB functionality, which hopefully will demonstrate as a viable option for creating a local TSN, allowing for high channel counts, and very low deterministic latency. If the standards are met, this should be the case!
The central tool on macOS I’ve found for working with AVB is available by opening a Terminal window and typing ‘avbutil’ this brings up the AVB utility, which includes several modules for working with AVB. From here you can type in ‘help’ and learn more about the structure and commands within the AVB Utility:
I usually start with ‘controller launch’ which brings up the AVDECC software interface. AVDECC stands for Audio Video Discovery Enumeration Connection and Control. Here’s a screenshot:
As you see from the image There are two AVDECC Entities near the top of the interface, as I’ve currently got 2 Mac’s connected and configured on my switch. By clicking on the Window Menu you can access the other AVB-related utilities:
The AVDECC Entity Controller is where you configure your AVB Audio Device, selecting sample rate and bit depth, but also Streams and Clock Sources. AVB Audio Devices work in Streams of Audio, each stream having 8 or more channels of audio. Basically, an AVB stream reserves a guaranteed amount of bandwidth on the AVB audio chain. Hundreds of channels are possible, of course this is contingent on your computer etc. But my MacBook Pro seems to be able to enumerate 31 streams of 8 channel audio at 48khz. I’ve not tested this, but also note that Streams reserve bandwidth, even if it’s not being used, so if you set up 4 streams of 8 channels, but only send 2 channels of audio, the bandwidth reservation will be the same as if all channels were sending audio.
The AVDECC Connection Matrix is also useful, consisting of a colorful array of AVB states, here’s an image:
With AVB configured, you’ll also see the AVB Audio Device in Audio MIDI Setup, where you can also change the sample rate, and clock source. Clock Sources on AVB devices are unlike typical macOS Audio Devices, having 4 selectable Clock Sources, shown here:
I haven’t got a solid grasp of the clocking between the different devices and protocols on my setup yet. But my switch selected the MacBook Pro as the Grandmaster Clock, so I’ve been using that. Otherwise, the AVB Audio Device seems to function like any other Audio Device.
In my next article I’ll cover the protocols and settings necessary to configure an AVB-compliant switch, both for isolated LAN’s, LAN’s with Shared usage (your home network), and WAN settings to consider for prioritization.