Sometimes the choice of equipment or cabling for a project is clear, driven by technical needs, cost, past experience, etc. But when new options arise, or issues are in conflict, what factors help make the choice? This article will look at issues to consider for a few common technology questions.
Fiber vs. Copper
Some years ago a client needed connectivity to move large video data files between equipment over a network. Advice from (non-technical) peers was that fiber optic was the only way to go. That had long been true, but at the time CAT6 cable was becoming common and capable of 10Gb/sec data rates. Not only that, the distances involved were tiny—less than 50ft. I had no doubt that CAT6 would work fine. It would be less expensive than the equivalent in fiber and SFPs, and could be field-terminated. I lost this argument because the client was just not technically savvy enough to believe me! So they got their fiber.
The price of fiber optic cable, SFPs, patching and other products continues to drop, so cost may no longer be a big factor. But using fiber to carry video or audio usually requires converters which must be added in, unless the gear has native fiber connections. And of course, fiber cannot carry power, so POE devices must be powered locally.
Being able to pull raw cable and add connectors on site can be important, and fiber is fragile. It has limitations on pulling force and bend radius and must be carefully prepped (with pulling eyes attached) to avoid damage.
On the other hand, fiber has massive bandwidth capability. Having a few dark (unused) fibers available between locations means you can add almost any kind of signal transport later, and distance is rarely an issue. You can even put many signals on a single fiber using wave-division multiplexing (WDM; different signals on different wavelengths of light).
So fiber can be considered truly “future proof” in most situations. I was glad to have some fiber already in place when a client unexpectedly needed to move 4K video between rooms. The existing SDI coax and network connectivity would either have not worked or required a lot of extra hardware.
What about multi-mode vs. single-mode? A lot of existing building infrastructure is MM because it was much cheaper for a long time. And that’s still the case for some fiber and equipment. But I usually go with SM now because it can handle more bandwidth and distance for long-term versatility, though the endpoints may be more expensive (see table 1).
Network Speed
When it comes to specifying 1Gb or 10Gb network infrastructure, again costs continue to drop. But a 48-port 10G switch is still a significant investment, and not sensible if the majority of traffic only needs 1G (and likely always will). Likewise, being sure that all the cabling could actually support 10G may add cost.
Two other points to keep in mind: Network connections require overhead for background traffic, so the data load should be kept below 80% of the stated bandwidth (800Mb for a 1G connection). And real throughput of network switches is limited by the backplane capacity. Just because the switch has 48 10G ports doesn’t mean it can actually handle all ports running at full tilt! This spec is readily available.
Looking at the kinds of traffic on an AV or broadcast/production network, the lowest bandwidth users are routine office tasks and internet. It’s pretty hard to top even 100Mb/s with a computer moving small documents, looking at websites, downloading software, or streaming video. Plus, for internet traffic you can’t use more bandwidth than the ISP provides anyway, which is often far less than even 1Gb.
The same goes for background functions like VoIP phones, security monitoring, smart building and IOT traffic, and remote control of production equipment (say robotic cameras). These are nearly insignificant bandwidth users. Even digital audio, like Dante, doesn’t ask much of the network in most situations because audio data is small.
Moving video is where speed starts to matter. Video files can be huge, so just transferring them between devices can be time consuming on a 1G or less connection. Plus, a few file transfers happening simultaneously “in the background” can impact other traffic on that same connection.
Performing large transfers after hours is one way to mitigate this situation. But that’s not always possible, so a 10G “pipe” in a strategic part of the network, say between a video server and a backup device, might be worthwhile.
Real-time uncompressed video for production, such as SMPTE ST2110, uses at least as much bandwidth as its baseband SDI counterpart, starting at 1.5Gb for HD at 30fps. Going up to 4K at 60fps requires 12Gb, so even a single 10G connection is not enough. This is the domain of high-bandwidth, high reliability “enterprise class” network equipment and infrastructure.
Video compression helps, but only so much. The makers of products that use NDI, for example, make it seem like adding sources and destinations to the network is no big deal. But regular NDI uses between 100 and 150Mb/s for HD (at least double for 4K). So assume that every new stream is adding another 150Mb somewhere, and the switch at the center is passing more data through between ports.
A worst-case example is something like a software multi-viewer or production switcher, which may have a single network connection to the switch. If eight NDI sources need to be sent to that one destination, we’re now pushing the bandwidth for a 1Gb link. That scenario calls for a 10G connection (or perhaps the heavily compressed versions of NDI in some cases).
Conversely, if a single NDI source is sent to multiple destinations, each of those destination streams is a separate network stream from the source, unless the system is configured for multicast. If not, then the camera feeding a switcher input, a recorder, and two monitors is using more than half the 1G available on its network connection.
The point here is that even systems using compressed video should be planned out with an eye toward network utilization, including individual port requirements, switch backplane capacity, and future expansion. Devices cannot be added arbitrarily forever.
Analog vs. Digital?
Some might find this a silly topic. Everything is digital today, right? For video, pretty much yes. Except for old systems and unique situations, it’s all SDI, HDMI, Displayport, etc. (or video-over-IP). And I would argue that this is (mostly) a good thing. But audio is, frankly, another story. We can think about two general families of digital audio: There is transport based on direct PCM data (which includes AES/EBU, MADI and a few other flavors). And there is audio over networks, like Dante, AES67, others. The latter is all we hear about now, even in the most mundane situations. And that’s where a decision point might arise.
Remember that audio in the real world is analog, and so are microphones and speakers. If you’re running a music studio with an analog mixing console and legacy tape machines, it might truly be analog end to end. But even if the mics go straight into a digital converter, and audio is edited in a DAW, out on the edges it’s analog. That is not the case with video.
A few years ago, I was asked for a proposal to build out a small facility consisting of two voiceover booths and six video edit rooms. The idea was that any edit room could use either booth, and each booth might have two to six talent mics (with talkback, etc.). My first thought was, sure, let’s use networked audio. Put the preamps in the booths, the audio goes on the network, anyone can get it. More networked audio for talkback to the booths.
I knew there would be some complications around how each edit room (running Adobe Audition and Premiere) actually accessed the audio and controlled the preamps, and that this would probably require operators to work differently than they had. I also knew that there would be a small ethernet network, which meant technology outside of their comfort zone. But I did a proposal based on this approach.
When the job finally happened, and I reevaluated the situation, I realized that networked audio was the wrong way to go. Even conventional digital audio didn’t make sense because all the signals involved were analog.
What I built was as old-school as it gets nowadays. Each voice booth has a small equipment rack with a connector panel and a headphone amp. The connector panels contain female XLR jacks that feed mic inputs on converters in each edit room, and male XLRs that return cue audio (talkback plus playback) from each edit room. Each edit room has just one piece of audio equipment, a Focusrite interface with eight mic preamps, cue capability, and USB computer connection. Fig. 1
To use a voice booth, an editor plugs the required mics into jacks going to the desired edit room, plugs the cue returns from that room into the headphone amp, and runs the session from the edit room. The only equipment and procedures to be learned were simple patching and adjusting the converter levels. Plus a little trickiness to avoid monitoring latency through the computer, which would be the case no matter how the signals came in.
Is this an elegant solution, or an old guy tragedy? Neither, it’s an appropriate choice for the client’s needs, and the client is very happy. Sometimes analog audio just makes sense. It really depends on the quantity of signals, distances, ability to run cables, flexibility of the mixer, and sophistication of the users.
Remember that the options still exist. And if you’re thinking that patching mic signals and running them between rooms would cause noise, please read my Analog Audio Interfacing article at https://www.svconline.com/needtoknow/analog-audio-interfacing.
