There's No Place Like 127.0.0.1

tl;DR AV and IT are not the same. Audio needs network training. AV and IT need to use each others skills. Type of training needed to understand audio over IP

If you get that gag you’re well on your way to understanding networking. It was one of my first Think Geek shirts back in Web 2.0. Think Geek wound down a couple years back after being tossed to GameStop. The pirate nature of the early internet days has been supplanted by a faux revolutionary facade. Pretty much the antithesis of the origins of the internet. Nothing exemplifies that like a pioneer of the early internet being the principal of a button up venture capital fund, part of the modern Sand Hill Road crowd. We all grow and mature. Hopefully that renegade spirit isn’t destroyed along the way.

Thanks for reading A Barking Dog! Subscribe for free to receive new posts and support my work.

I’ve told this story countless times but I got my first taste of local networking early on. Prior to the widespread use of LANs I was using old school service like Compuserve or the good ol’ Wildcat BBS systems of the dial up days. I should make a modem handshake my ringtone. Traveling from the walled garden of the Compuserve Live Sound International forum to the first incarnation of live-audio board listserv to the Perl driven live-audio board forum I got my degree from the School of Hard Knocks. From there a shared hosting account on a DEC AlphaServer at Northwest Nexus in Bellevue. Then dedicated servers at Best Internet in San Fransisco then Rackspace in San Antonio. Using the RaQ appliance at Rackspace convinced us to buy one and park it at Speakeasy in Seattle. From there it was building Prosound Web with Crazy Uncle Kenny in a cage at Exodus SE2 with Solaris and Linux boxes. Good times. Mostly.

With the push to merge IT and AV, or at least have some convergence along the way, some suggest that now AV and IT are nearly the same thing. Negatory Pig Pen, negatory. We share many of the same technologies but regardless of any sort of network convergence the applications are radically different. I say this as I’ve seen from some in the IT community there is a lack of understanding about what exactly what it is we do. And how we do it. Application is key. The pandemic brought remote workflow through Zoom and Teams meetings. That got those in IT involved in the corporate campus AV world. All of the sudden remote access wasn’t just a nice thing to have but a necessity. The IT staffs then needed to set up for different protocols and methods accessing the network. Not AV but certainly in the middle of it.

I don’t mean to imply that many in the AV set understand networking as much or more than the IT geeks. Far from it. On the AV side we do have a fair amount of experience implementing IP networks however pedestrian in design. The most basic and generally prevalent config for the bulk of live gigs would be a couple/few stage racks, a console or two and perhaps some Dante enabled radio mics. Throw in some IP control for your drive system or remote console control for good measure. Right now that config does a good portion, perhaps most of local and regional gigs in the biz. Not too much different than a copper analog infrastructure.

Over the last couple of years the speaker drive chain has increasingly moved toward an all digital topology. We’ve reached the point where we can operate with exactly two analog conversions. One at the mic and one at the loudspeaker. Gone, or at least disappearing quickly, are the days where we round trip the conversions three perhaps four times to make it from muso to punter. We get reduced latency and uniform conversions in the way of sampling rate and bit depth. Win, win. The downside is with more elaborate systems we get more complexity.

For a larger touring gig more complexity and variables are introduced. In addition to the above there are direct to network playback rigs, system drive control and matrixing with perhaps a smattering (or even full blown) spacial panning/movement system. Guess what? It may not be the same audio over IP protocol in some of the subsystems.

Worst case you could have three or four AoIP protocols in the system. I’ve seen that movie. Three proprietary forms of AVB, Milan AVB, Dante and Q-Lan. And nearly a dozen control protocols over IP. Add a collapsed core switch topology, a dozen VLANS, some Layer 3 routing and the 18 computers used to control and feed content to them and that’s a varsity configuration. If you’re connecting to the wide open internet a firewall with a well defined ruleset will be added to the list. Now we have an IT worthy rig. One that most of us sound tweeps won’t be familiar with. Perhaps a few but not most.

This is where IT comes in. We say IT but it’s the networking portion of IT that we mean. IT encompasses an entire realm of corporate computing technology most of which isn’t part of our use cases. Specifically we need to work with networking engineers and techs to share network infrastructure. The more complex and larger scale the more we need them. They need to have a minimum understanding of our basics like time sensitive networking, the deterministic aspect of some of the protocols and what can exist together on a single switch due to clocking considerations. In network audio clocking is key. No clocking, no Clockwork Orange. Says your humble narrator.

Not only do they need to know what we need, we need to know what to ask for and how to ask for it. We need to understand the basic requirements of a network and how what we are asking for fits in. We need to know what can be converged and what can’t. We need to design our subnets that connect to the main net in a way that is relatively straightforward. Networking can get complex quite quickly. Working to reduce network complexity while still providing the services you need at the quality required is going to require we learn more about networking. Every audio tech doesn’t need to know this but we need more than we have now. Just as we need more networking pros to understand the application of AV and basics of AV than we have now.

We need to learn general network basics like addressing, sub nets, switch topology and config, VLANS and trunking. We need to know technologies and protocols used specifically in our gear. PTP in its various flavors, mDNS, multicast or unicast and deterministic networking are a few. This helps us use and maintain these networks faster than someone with a network engineering background is going to master Q-Sys or a related AV app.

IOW generally speaking we don’t need as much networking knowledge as they’ll need AV knowledge. We are only using a small subset of what they use/learn. Unless you dedicate some serious learning and get experience you won’t likely be able to design, monitor and troubleshoot a network in a way a network engineer could. The goal is a happy medium where there is a symbiotic relationship. Avixa has an online class on this very subject. It’s geared toward IT working with AV but both fields should read it. It’s at https://www.avixa.org/av-for-it-pros

My diatribe is directed more toward us mooks that gig live events not so much corporate campus AV. Unless you’re in a corporate environment where some physical nets have to be completely abstracted and separate for other nets with hardware (think casino surveillance and gaming) you’re likely going to be riding on the corporate net on the corporate campus. Integrators have taken to hiring networking engineers to add to their design teams as a result of the increasing requirements from corporate clients. They have to. You need it these days. These days an audio system is a bunch of computers tied to a network in order to make sound. My Digico doesn’t look like a computer but it is.

So we’ll need some training. These days for an advanced audio networking pro I’d look for some or all of the following. I’d look for someone that has a knowledge of what an IP network is and how TCP, UDP and mDNS protocols work. Knowing IP addressing and how to calculate subnets or at least read the chart and know what they mean. How Layer 2 and Layer 3 switching works. Familiar with how different core switch topologies work. Be familiar with how multicast works. Know what a VLAN and trunk is and why it’s used and as a bonus be able to design and configure them. Know about time sensitive networking as well as the various flavors of PTP. Know how to calculate bandwidth. Know which troubleshooting tools to use and how to use them. At our scale monitoring the network is still largely the domain of whatever control app you are using. Monitoring mechanisms specific to AV similar to what’s used in datacenter and corporate IT networks are coming. It will be more than Wireshark and a command shell.

That sounds a lot like network engineering because it is. It’s a lot for us but just touching the surface of what a network engineer needs to know. It’s been plenty for me as an audio wonk. There are several ways to get the knowledge but few in which to implement them without access to real world gear. The virtual labs from Cisco and Pearson are great but not specific to AV. My go to for show related networking is John Huntington’s wonderful Introduction to Show Networking. If you do better with a more structured method such as class or online there are resources for those as well. For general networking the Cisco Networking Academy is good though concentrates on Cisco devices and general networking. CompTIA Net+ is another but still specific to general network engineering.

While you can take these there is much more offered for the cert than most of us need. Just after the shows opened post pandemic I was going for a Cisco Certified Network Associate or CCNA. I was about a third of the way through when I started to put in a show on the block. By the time I got done putting the show in (about a year) I realized that Cisco specific training wasn’t something that would provide me the best value. Using mostly Netgear and Luminex gear in the new shows defeats the purpose of Cisco specific training. It’s a lot to weed through for non manufacturer network knowledge.

For most of us my suggestion is to use John’s book as a self study and combining that with Dante training. You can take the Dante bits online. Dante Level 1 and Level 2 training is all most users will need. For those that design AV networks Level 3 will be necessary. That takes care of Dante and IP basics but doesn’t touch on the other protocols like Ravenna or AVB. Ravenna, used primarily in broadcast has a good resource for an overview to a deep dive. Avixa has started to offer an AV Networking Professional certificate but it’s still in the beta stage.

If you’re working with AVB, Milan or otherwise there are fewer interactive training options but there are still resources available. It’s not from a central source like Dante training. It’s provided by the manufacturers of whatever AVB device you’re using. While there isn’t much training on interoperability between manufacturers there is some on specific systems. As in here’s how it works with our box. Avnu, the trade group promoting AVB is more focused on supporting manufacturers certifying equipment rather than end user/implementor knowledge.

The protocol and programming interface is open source but in application each manufacturer implementation is largely an island. A single protocol works well when your environment is homogeneous without supporting other AV protocols in the building. Big PA on tour? Killer. Install in a theater or corporate campus? Not so much. Interoperability is possible but not promoted except in a few cases such as interfacing one manufacturers console with another. It’s not difficult it’s only the siloed culture of manufacturers are promoting compared to Audinate showcasing multiple vendor devices in a single network. Neither training though showcases interfacing to completely different protocols. That’s an area we’re largely left to figure out on our own with the help of the few that make boxes that interface disparate networks.

As there is no central authority selling AVB user training is left to the domain of any specific manufacturer. It’s similar to how Linux was in the early days before Red Hat started the first (that I know of) formal training. Perhaps with the upcoming Avixa ANP cert they’ll offer some structured AVB training featuring interoperability. Regardless of the protocol network basics apply to each one.

Some training is going to get you to be able to wrangle a moderately complex audio network. There is nothing like experience though. Training is one thing, doing is quite another. Getting your hands on a couple of endpoints and a Layer 3 switch will go a long way to developing your skills. It won’t be too long before you’re well on your way to being the one that knows networking on the gig.

Thanks for reading A Barking Dog! Subscribe for free to receive new posts and support my work.