It’s the hot topic, the current buzzword, the latest and greatest and so forth and so on — it’s AV on/over the network.
But stop and think — do you actually need one? Do you just crave one? Can you afford one???
There is certainly a lot of product out there in the sound reinforcement and production markets that has “network” capability prominently promoted and more is arriving every day. You can get plug-in cards for almost any device to make it ‘network-ready’ and the networking hardware itself is becoming less expensive almost hourly, with more vendors than I can count offering solutions.
Major trade organizations have been aggressively supporting networkization (my term), with lots of seminars and sessions on AV over IP/IT and a gazillion related topics. It’s been the front line theme of expos, conventions, academic meetings and conferences around the globe for at least the last three to five years, and there is no indication its highlight status is fading.
It is being persuasively pushed to a front-of-mind spot across almost every professional audio/video market segment, and has become a dominant topic in the pro-broadcast and production communities as well as their subsets in the HOW space, academic space and meetings industry, just to name a few.
So it’s no surprise that you and your AV team/colleagues are thinking about it and looking into it. But is a network something you should be devoting time and resources to?
Let’s Back Up a Bit First
It is essential to recognize that network deployment automatically means concomitant software deployment — and that immutable fact, in and of itself, should be sufficient cause for some very introspective and careful examination. But why, you might ask?
Consider the following carefully. In multiple recent articles and studies published in The Atlantic, The Verge, Ars Technica, Forbes, Bloomberg, to name just a few major sources, numerous IT/IP analysts have all made the same point, which boils down to: Software is overwhelming the world. This is not being said with great joy but serious concerns.
Well for starters, think about this. Ever increasing numbers of both everyday use and critical/emergency systems that were formerly operated either automatically (or by actual people) are becoming lines of software code.
Second, ALL software comes from and lives in a very different mind-space. For example, simply by changing one number or one word in a code’s text file, which could be running on a server in another galaxy for all you know, the same CPU or DSP chip can become an airport train controller, an inventory tracking system or a loudspeaker management processor. The silicon knows not, it simply executes the code supplied.
This elasticity is software’s miracle and its curse. The rub is that software is a ‘because I can product.’ Because it can be changed economically, it is constantly changed, i.e., it’s never actually final. How many programs do you use that are up to version 30 or revision 107? Do you think that constant stream of updates and changes will ever stop?
But uniquely, since the code/software is not anchored to anything physical, it means that a program that is 10 times more complex takes up essentially the same tangible space, allowing uncontrolled and not always useful growth.
Want proof? Go back and check the size of MS Office 10 years ago and check it today. Here’s what you will find — in the 2003 version it was about 300 MB, by 2007 it was >488 MB and by 2010 it had grown to close to 1 GB for the pro version. And it just keeps getting bigger. It’s like an ever-expanding supernova explosion of code with massive functionality left unused by 80+ percent of users.
As a culture, we are attempting to build systems that are clearly ahead of our ability to actually manage them. When software fails (and it will, often), nine out of ten times the resultant diagnosis produces this result: “The software did exactly what it was told to do. The reason it failed is that it was told to do the wrong thing.”
So as you consider the concept of a network, and read on about that below, also consider this. The essential problem with making things out of code is that the actual complexity is all but invisible to the eye of the coder, let alone the user.
With a million lines of code considered a tiny program now-a-days*, it is simply not possible to find every possible mistake, error or misplaced digit. Therefore, if it’s based on code it will develop some flaw — you just don’t know who might do what, or when that will be or what effect it will have when it does happen. Since all networks are also built from and around code this means they too have that built in flaw. (*On average, 2018 vehicles have 30-50 ECUs or electronic control units — containing upwards of 100 million lines of code — just for reference. We got to the moon with 1/10,000th of that computing power.)
Entering the Altiverse* of Networking
Note: Altiverse is the author’s term for the strange, wonderful world of networks.
There you sit pondering the possible deployment of a network for/within your HOW AV system. As you deliberate consider these three key questions:
- Why are you doing this?
- What is the ROI?
- What are the downside issues?
If you don’t have clear, precise and justifiable answers to these questions, I suggest you stop now. It is critical to have a full understanding of both the positive and negative of going down the network road.
You will more than likely be relying on some other resource (inside or outside) for specific knowledge and guidance in this quest. Their ability to understand your precise needs, goals and procedures is essential to getting a useful answer to the questions posed and making a logical decision on the path to choose.
The IT altiverse is a very complex multi-dimensional world of its own and operates within a set of guidelines and technical specifications that can easily overwhelm even experienced AV technical team members. Getting your chosen network guide to explain things to everyone in terms that relate to how they work and what they do is not only essential, it’s the only way to be sure everyone is comfortable with this decision and will be able to make use of the new systems effectively.
Remember that as a rule, people will remember a totally random sample of the information given to them and that sample is most likely not going to be the summary you wish you could hand them.
It’s a random set of data, which will be different for every team member. You need to control this process and make the information into simple, bite sized blocks of comprehensible ideas.
On the Network
You have completed your review and are seriously thinking about going on the network. Before you do, take one more look at the why of your decision.
If you are a single location, with a small to medium sized worship space, a network may simply be nice to have but not necessarily additive to the functionality of your day to day work environment. If you fit this description, consider very carefully what you expect to gain by adding this to your system. Make a list of the positive changes a network will bring to your specific HOW and discuss them with the whole team both technical and worship. Are you really sure you need to do this?
On the other hand if you are a multi-site HOW and with plans for further expansion then a network structure probably makes good sense both short and long term as it will open up a number of options and add to the technology capabilities, making things like broadcast and remote location coverage much easier.
If you fall some where in between these two categories, as most HOWs in North America will, then the decision comes down to what do you gain for how much?
Additionally, if like many organizations you already have an office network/Wi-Fi system for connecting computers, printer and related devices, do not consider that network as an option for your AV needs. The demands placed on AV networks for bandwidth, latency and many other technical specifications usually far exceed the available capacity of your ‘office’ network system(s). Leave that system alone if you intend to go networked AV — you will need a dedicated new system for that purpose.
Just to be absolutely clear, this article is focused on the transport of audio signals on a network. Most certainly you can carry other signal types including video, control and data on a network, but the protocols and codec, encoding and decoding requirements will be significantly different.
One crucial point to consider when deciding on a network roll-out is whether it will be used for multiple signal types or a single signal format such as audio in this example. With the increasing available of Time Sensitive Network (TSN) hardware and protocols that accommodate such requirements the ability to deal with multiple signal types on a single network infrastructure is somewhat less cumbersome but still requires very very careful pre-planning and a complete understanding of the bandwidth requirements and total network latency issues. While there are claims of zero latency it’s very hard to actually achieve that in the real world, so be cautious when evaluating both hardware and designs with such claims.
If your decision is to move ahead and install an AV network structure you will first face a which topology choice. There are three currently in use CobraNet (the oldest and mostly legacy oriented), AVB and Dante from Audinate.
While a detailed discussion of the pros and cons of each system is well outside the scope of this article (and there are dozens of books and gigabytes of online resources on the topic), suffice it to say that by default the Dante technology is the generally accepted option. Almost any hardware you might want to add or connect will have a Dante card option or connection method available. It has become the de facto choice in AV and thus it is probability the one to consider for your needs.
The graphic above outline and depicts a typical AV Dante network structure — while it does not specifically show HOW options the information is useful and applicable. A lot of additional on-line video content is available from this source and many others and it is well worth the time to review all of this information before doing anything specific.
Below is a graphic depicting a typical network structure discussion tree. It is a really good idea to go through these steps when deciding what to do and how to do it.
Once you have completed this step you can move to deciding how to layout your network. Below are two typical examples.
While these examples are typical, every network is unique to the facility and the hardware it connects to and with. Your eventual structure will begin with something like the systems above but should evolve to meet your individual needs and requirements. And don’t forget to build in expansion and extension capabilities- they will be needed down the road, even if that is not obvious right now.
No Matter What
If a network is in your plans, the three critical things to remember are:
- AV networks are specialized systems of their own- standard network gear may not apply.
- Get expert advice and be sure to check the qualifications of your expert for both IT and AV expertise.
- Check, re-check, and re-check your finished system for functionality and connectivity — there are a lot of places for problems to develop and you don’t want those occurring during a service or live broadcast!