With the widespread adoption of IT networks and technology, the landscape of AV and broadcast media has become much rockier. We are now working daily with technologies that were never intended for AV, are drastically different than what we’ve had, and are part of a large and complex ecosystem that developed in a different industry.
All of the technology we work with in AV has history, rules, jargon, and misunderstandings (see other articles from this author). IT tech is the same way, so the merger of IT with AV means adding a whole new world of history, rules, jargon and misunderstandings.
Here’s a real-life example: on some digital mixers, Behringer uses AES50 connectivity to move audio between the mixer and various stageboxes. It can carry up to 48 audio channels and connects with a simple CAT5e or 6 cable. A typical scenario is a direct cable between the mixer at front of house, or an audio control room, and the stagebox near the talent. Works great under 300ft, give or take. But I had a situation where the stagebox needed to be farther away, and there was already single-mode fiber in place. Could this work?
AES50 is a non-proprietary protocol for moving digital audio data, standardized by the Audio Engineering Society. But unlike AES3 and MADI, which carry PCM digital audio streams in their native form, AES50 packages the data into frames so it can travel on network hardware. I did not need any switching or other data manipulation, so it seemed that basic Ethernet media converters could convert between the CAT cable (with RJ45 plugs) and fiber, then convert back at the other end.
But when I dug deeper I started to suspect it wasn’t that simple. For one thing, Klark-Teknik already makes a family of products for extending AES50, and they are much more expensive than Ethernet media converters. Wikipedia provided a good start, while reading posts on the Behringer user group was a mix of useful info and erroneous nonsense. But it was surprisingly difficult to find enough information to validate my idea.
Finally, I turned to the AES standards themselves (AES50-2011 and AES-R6 supplement) where I discovered the truth. AES50 was designed to operate on 100Base-TX Ethernet, which uses only two pairs in the cable for data. This is where the audio frames go. The other two pairs are used for sync information between the two devices, and this is not in ethernet frames. In fact, it is nothing like network data, and I don’t believe a media converter would pass it. Since AES audio won’t work without proper sync, the idea was a non-starter. Rats!
Interestingly, while Behringer and Midas use AES50 for digital snakes, other manufacturers use various similar, but incompatible,protocols, some of which are proprietary. There is a useful list at this Wikipedia page: https:// en.wikipedia.org/wiki/Audio_over_Ethernet.
Unpacking
Given all the concepts buried in the example above, it’s pretty amazing that anyone can buy a couple Behringer products, connect them following a few instructions, and it works! That’s a credit to the people and organizations that develop standards, and to the manufacturers that manage to implement these advanced technologies in (mostly) friendly ways. But unpacking those concepts gives an idea of how much there is to understand.
And many new technologies are not simple enough to be implemented in a user-friendly way. It seems to me that the AV industry today is mainly being driven by manufacturers, many of which are deploying increasingly complex technologies to provide capabilities that we can offer to our clients (for better or worse). But these advances also put a greater burden on us to become experts in more areas and provide support for systems that are well beyond the understanding of the end-users.
And that is really the point. Manufacturers are trying to make these technologies easier to use— mainly because it’s better for business—and this can be successful in some cases. But if you want to deploy systems using the IP-based options we have now, at some point you will need to know what makes it all tick (see accompanying table).
What Is Ethernet?
Getting back to the exciting title of this article, the term “ethernet” gets used casually in many ways that are inaccurate. As with many technical terms, the meaning has been diluted by inexact usage in different places. This doesn’t necessarily matter as long as all parties understand the context. But it often matters to me because I’m trying to do something specific.
Ethernet is a standardized method of data transport for Local Area Networks. It can run on copper, fiber or wireless (yes, Wi-Fi is Ethernet). Alternative methods which are becoming defunct include Token Ring, FDDI, and ArcNet.
Knowing that a network is built on Ethernet does not tell you anything about what data is being carried, how traffic is controlled, who has access, etc. All those are handled at higher layers of the OSI model. But for most purposes today, Ethernet is part of a network that uses the Internet Protocol Suite (aka TCP/IP), which includes a vast collection of protocols that manage the data at different layers in a four-layer networking model (abstracted from seven OSI layers). Note that the TCP/IP Layer 1 (network access) combines both OSI Layer 1 (physical) and Layer 2 (Data Link), so it can be hard to tell where “Ethernet” really lives–particularly with a protocol like AES50 that doesn’t use true Ethernet frames.
It goes without saying that this stuff is dreamed up and implemented by some very smart people, with the rest of us playing catch-up most of the time. To get even slightly on top of this snake’s den means getting educated via some means. There are classes from Cisco (CCNA), CompTIA, other organizations, colleges, and online. If you need to work on any serious Dante, AVB, NDI, ST2110, or other “over IP” deployments, work with live streaming, or just manage the equipment on a network, you need this knowledge!
Moving on, because CAT cables are directly associated with ethernet, people often think that any use of that cable (with an RJ45 plug) means a “network” connection. This could not be farther from the truth, since that particular physical form is being used for all kinds of signal connections— everything from analog audio to DMX data to DC power. This is because of the small form factor, useful internal structure (four twisted-pairs) and general ubiquity of this cable type. You can call them “ethernet” or “network” cables as shorthand, but don’t assume anything!
The potential for confusion also arises when talking about Ethernet, networks, and “The Internet” without care. As consumer technology has evolved, and service providers jockey for business, terminology is regularly misused and misunderstood. Wi-Fi is nothing other than the wireless version of Ethernet on a local network. And, as we know, sometimes it’s better to use wired connections for reliability and bandwidth.
Wi-Fi is not The Internet, but I suspect a lot of people think it is because they use Wi-Fi to access the internet. What that really means is they are connected to a local network, and that network routes to one or more other networks, which eventually get to an Internet Service Provider which is connected to what the Internet really is: a “network of networks.”
Likewise, what is a router, and what is a “Wi-Fi router”? A network router is a device that connects two distinct networks (Layer 3 in the OSI model). A Wireless Access Point (WAP) is mainly concerned with sending and receiving data on the particular network it is part of; it knows nothing about routing. A router that includes a Wi-Fi radio combines the functionality of a router and a WAP; it routes between the ISP’s network and the home’s LAN, and it provides wireless connectivity on that LAN. This is particularly useful for home users, not so much for commercial installations.
So now we have people tossing around terms like “router” without knowing the exact meaning, which can lead people like myself to misunderstand what’s going on in a situation. The same happens with network switches, which are OSI Layer 2 devices in their basic form. Switches are the heart of a network, but are not responsible for everything that happens.
In fact, any two devices connected via Ethernet constitute a network and can (potentially) function without switches or routers. For example, I installed a MOTU audio processor to help distribute background music in a restaurant (another story). The processor supports remote control from a browser, so I can access it with a phone or laptop via Wi-Fi and make adjustments in the room. I connected a simple WAP directly to the processor and gave them both network addresses (no DHCP here). When I put the address of the processor into my phone, it connects and the MOTU webGUI comes up. Instead of plugging my laptop directly into the processor, the WAP acts as a wireless conduit. Arguably the WAP doesn’t even need a network address, but it was necessary to access the WAP’s webGUI for setup.
This is all made possible by the various protocols and hardware specifications employed in TCP/ IP networking which are standardized by various organizations. The more you know about it, the better.
