Bandwidth and QoS are interesting topics when it comes to media networking. There are some key differences at the network utilization level with real-time media streaming when compared to typical datatypes that exist on a network. Non-media data tends to be very ‘bursty,’ meaning chunks of data are transported around the network as and when they are required. Bandwidth utilization will naturally show peaks and troughs and as more users and data are added to the network, it will level out to some degree, however; the traffic is still bursty. Uncompressed professional audio is completely different. A collection of audio channels travelling from point A to point B will have a fixed, constant bandwidth utilization with virtually zero peaks or troughs. This casts a different outlook on bandwidth and QoS, which is common in the IT industry.
With professional audio, the amount of bandwidth required is directly proportional to the number of channels and how they are packaged on the network. A single 16-channel stream will require less bandwidth than 16 single channel streams. This is because each stream has a certain amount of IP header information. If you can combine all channels in to a single stream, you are being far more efficient and therefore require less bandwidth. Uncompressed audio bandwidth requirements are very predictable and very constant.
Video is Different
The bandwidth required for full HD or 4K video to traverse a network is so large that compression techniques are regularly used. With that comes a huge amount of variability. Constant bit rate codecs do a good job of providing reasonably fixed bandwidth utilization on the network but even then a variation of ± 20 percent is not uncommon. Variable Bit Rate codecs can have dramatic peaks and troughs which makes it similar to ‘bursty’ data on the network. The key difference is that it is very periodic, meaning it is much more predictable than non-media data.
All of this is good news. We can predict our bandwidth requirements and therefore ensure that the network is up to the task.
It’s important to note that QoS provides a couple of key benefits to our network. First, QoS helps the switch decide what to do if there is more data present at the switch port than can be sent down the cable. QoS allows the switch to decide which low-priority data to drop to ensure high-priority data gets to where it needs to go. However, a very significant behavior with QoS often overlooked, but critically important to real-time media, is that QoS helps the switch ensure high priority data is transmitted on time. This is particularly important when we start to talk about digital audio systems.
When we moved from analog to digital audio, we learned very quickly that a good, jitter-free Word Clock system was important to ensure digital equipment was synchronized correctly. Without digital sync, audio devices would create nasty pops and clicks, or just not work at all. Networked audio has very similar requirements from a synchronization standpoint except on the network we often use a PTP network clock synchronization system. As was the case with Word Clock, to avoid that jitter (or time delivery variance), timely delivery of PTP is very important. Typically, we aim for PTP to be delivered with as close to zero variance as possible, but commercially available systems are able to tolerate variance in the region of 10-50µs before things start getting challenging.
The actual audio content is less time sensitive than the PTP sync because the audio is buffered on the receiving end before playback so variance in this regard is far less of a problem. And finally, networked video streams are even less time sensitive than audio since we are typically dealing with only 60Hz playback frame rates.
QoS allows the switching infrastructure to prioritize the timely delivery of the synchronization, audio and video content to ensure those subsystems work correctly.
The point here is that from both a bandwidth usage and QoS requirements perspective, real-time media is very predictable, which means very manageable.
Application for AVB
In a small system with only media data on the network, you might decide to set up the network yourself. The system might work ‘out of the box’ or there might be a few small changes to the switch configuration, typically focused on QoS, based on manufacturer recommendations. Alternatively, you could utilize a system that automatically configures the network. AVB is great in this application. Using AVB-enabled endpoints on an AVB-enabled network is like having our own IT expert on-hand to setup the network.
However, it should be noted that with all the benefits AVB brings, the automatic bandwidth reservation and prioritization functions may be unsuitable for a complex network design or one that is managed by an IT department. It is the role of the IT administrator to manage the network, make QoS decisions and implement them. Sometimes that means placing non-media data at a higher priority than media. When we automate those processes (as AVB does), we limit the ability for IT to manage the network in its entirety.
Martin Barbour is the product manager of Installed Systems at QSC Systems.
Info:
qsc.com
