A Network for AV Is Not the Same as an AV Network

Last week I once again sat down with an AV reseller to discuss a larger AV project. The reason for the meeting was a familiar one: the end user was experiencing disturbing clicking noises in the audio, unreliable behavior, and a system that did not meet expectations.

The issues persisted, and with them the doubt grew. The conclusion was quickly drawn by the end user:

“The AV hardware isn’t working properly. It needs to be replaced.”

On the surface, that conclusion makes sense. When users hear clicks in the audio or notice that a system behaves inconsistently, their attention naturally shifts to the visible and tangible components: microphones, DSPs, amplifiers, encoders, decoders, or other AV equipment.

Based on that assumption, the project was reset. A new AV reseller was brought in, and a new design was created. New hardware was selected—modern, IP‑based solutions suitable for high‑resolution video and critical audio.

So far, nothing unusual.

But then the conversation turned to the network.

And that’s where things got interesting.

Specifically installed for AV

What made this case particularly interesting was that the network was not an old or generic office network to which AV equipment had later been added.

On the contrary.

The cabling and switches had been installed not that long ago, specifically togeter with the previous AV installation. On paper, you would therefore expect the infrastructure to be suitable for the task.

And that is exactly where the trap lies.

Because installing a network for AV does not automatically mean the network is actually designed for AV‑over‑IP.

The question is not just: Is there a cable?
The real question is: Does the topology make sense, is the switch selection appropriate, and can this network handle AV traffic in a reliable and predictable way?

Taking a closer look at the design

When analyzing the existing network design, the vulnerability quickly became clear.

The network design of the previous AV installation was not a Spine‑and‑Leaf architecture, but rather a daisy‑chain structure, with switches connected one after the other.

This is a design approach you still encounter fairly often in traditional IT networks. But in environments with real‑time audio, multicast video, and high‑resolution AV streams, it becomes far less forgiving.

An important detail: the switches used in the previous project were unfortunately not from NETGEAR, nor were they selected with this type of AV application sufficiently in mind.

As long as network load remains limited, such a design may appear to work just fine. But once multiple audio and video streams are active at the same time, the topology itself starts to matter.

Not always visible.
Not always immediately measurable.
But definitely noticeable.

And in this case, even audible.

Audio is unforgiving

Video can sometimes get away with a brief hiccup. A dropped frame or a slight delay often goes unnoticed.

Audio is different.

A small network instability immediately translates into something everyone hears: a click, a crackle, or a brief interruption. And at that point, it does not feel like a network problem to the end user.

It feels like a bad AV system.

That is exactly why AV hardware is so often blamed first. Not because it is actually the root cause, but because it makes the problem audible.

The end user doesn’t hear a multicast issue.
They don’t see a topology problem.
They don’t think about latency, jitter, buffering, or uplink capacity.

They just hear clicking audio.

So it seems logical to point at the AV solution.

New hardware, same problem

What continues to stand out to me in projects like this is how quickly new AV hardware is seen as the solution to problems that actually originate in the infrastructure.

But if the foundation isn’t right, the problem is simply carried over into the new system.

In fact, modern AV‑over‑IP solutions often place higher demands on the network. Higher resolutions, more simultaneous streams, real‑time audio, and tighter timing all increase network load compared to earlier systems.

New equipment does not ask less from the network.
It usually asks more.

And that is when a design that once seemed logical suddenly becomes the bottleneck of the entire system.

In this case, the core issue was not poor AV hardware. Nor was it outdated cabling—the network had been installed specifically for AV.

The challenge lay in the combination of:

• a daisy‑chain network structure
• the selected switches
• and heavy, time‑critical AV traffic

That makes it not a product problem.

It makes it a design problem.

Switch selection matters

A switch that works perfectly fine in a general data network is not automatically suitable for every AV‑over‑IP environment.

This is not necessarily about good or bad—it’s about suitability.

How does the switch handle multicast traffic?
Is the configuration appropriate for real‑time data flows?
Is there sufficient uplink capacity?
What happens when audio, video, and control traffic all traverse the same paths simultaneously?

In a daisy‑chain structure, these questions become even more critical. Every device further down the chain depends entirely on everything upstream. A single overloaded uplink can affect the entire system.

And that makes issues particularly tricky.

Because the system is rarely broken all the time.
It usually works fine—until it doesn’t.
Until everything is active.
Until the moment when it really has to perform.

What I want to share from this project

What I want to share from this project is that, in AV‑over‑IP, we need to look beyond the equipment itself.

A solid AV network does not start with the question of how to reuse existing cabling as cleverly as possible.

It starts with the question: What does this system need in order to function reliably?

Sometimes that means additional cabling.
Sometimes a different topology.
Sometimes different switches or a different configuration.
And sometimes, most importantly, an honest conversation early in the project about the limits of the design.

That conversation is not always easy.

But it is always better than troubleshooting issues later that could have been prevented with a different infrastructure.

Conclusion

The core issue in this case was not the AV hardware, and it wasn’t the fact that the network had been installed specifically for AV.
The core issue was the mindset used to design the network.

The network was designed using classic IT thinking: efficient use of cabling, flexibility, and an acceptance of buffering and latency. That works perfectly well for data traffic—but it clashes with the requirements of real‑time audio and video.

AV‑over‑IP calls for a different starting point.
Not: How do we fit AV into an IT network?
But: What kind of network does AV need to function predictably and without disruption?

As long as AV networks are designed using IT logic as their foundation, problems will continue to surface where AV systems are most sensitive: in audio and video performance.

So the real solution is not replacing AV hardware, but designing the network as an AV network, from the very first sketch.

I’m curious how others experience this.

Are AV projects still too often designed around existing cabling instead of application requirements?
And do we sufficiently challenge the network design—even when the network was “specifically installed for AV”?

Want more background information? Read my blog about the AVoIP pyramid.