Ten years ago, a mid-size commercial audio system had a recognizable shape. A fixed-I/O digital signal processor sat in the rack — eight in, eight out, maybe twelve by eight if you bought the bigger box. Every microphone, every source, every amplifier channel came home to that rack on its own shielded analog run. If you needed more inputs, you bought a second processor and tied the two together with analog links or a CobraNet card, and you lost a little signal quality at every hop.
That architecture is effectively gone from new commercial work. Not because analog processing sounded bad — a well-configured Soundweb or Nexia rack still sounds fine — but because the thing it was optimizing was never the processing. It was the cable.
Here's what actually replaced it, what the change demands of the building's network, and the places we most often see it done badly.
The Analog Rack Was a Cabling Problem Pretending to Be a Processing Problem
Consider a 40-zone restaurant and bar. Under the old model, that is 40 home runs of speaker cable back to a single amp rack, plus line-level runs from every source, plus a dedicated run for each paging microphone and each wall plate. The processing box in the middle was 3 rack units. The cabling was most of the labor, most of the conduit, and most of the cost.
Networked audio inverts that. One Cat6A run to a closet carries dozens of channels in both directions. Amplifiers move out to the zones they serve, so speaker cable runs are measured in tens of feet rather than hundreds. The processor stops being a box with a fixed number of holes in the back and becomes software running on a general-purpose processor — in the Q-SYS case, a Linux-based Core running on x86 hardware, where channel count is bounded by CPU headroom rather than by card slots.
That last point is the whole reason this article exists. The technology is mature and well-documented. The failures we get called in to fix are almost never DSP failures. They are network failures wearing an audio costume.
What "Networked Audio" Actually Means
Three transports account for nearly everything in commercial work, and they are not interchangeable marketing terms.
Q-LAN is Q-SYS's native transport. It runs on standard gigabit Ethernet, clocks with PTPv2 (IEEE 1588), and supports a fully redundant dual-network topology — LAN A and LAN B on physically separate switches, with failover that is inaudible.
Dante is Audinate's transport and the de facto interoperability layer: microphone arrays, amplifiers, interfaces and consoles from hundreds of manufacturers speak it. Latency is selectable, with 1 ms the common default and 0.25 ms available on a well-behaved single-switch network.
AES67 is the open standards-based interoperability profile — 48 kHz, 24-bit, 1 ms packet time, PTPv2 clocking. It is the bridge between ecosystems rather than a full ecosystem itself: it moves audio, but not the device discovery and control that Dante and Q-LAN provide natively.
| Transport | Typical latency | Clocking | Redundancy | Channels per 1 Gb link |
|---|---|---|---|---|
| Analog home run | None | N/A | Per-cable | 1 per cable |
| CobraNet (legacy) | 1.33–5.33 ms | Conductor election | Limited | 64 (100 Mb bound) |
| Dante | 0.25–5 ms (selectable) | PTPv2 | Primary / secondary | ~512 @ 48 kHz |
| AES67 | ~1 ms packet time | PTPv2 | ST 2022-7 (if supported) | ~400+ @ 48 kHz |
| Q-LAN | ~1–4 ms (configurable) | PTPv2 | Dual LAN A/B | ~500 @ 48 kHz |
The channel-count column is the one that reframes the whole conversation. A single 48 kHz, 24-bit channel is about 1.15 Mbps of payload — call it 1.5 Mbps with packet overhead. Sixty-four channels is roughly 100 Mbps: a tenth of one gigabit port. The bandwidth was never the constraint. Timing is.
The Switch Is Now Part of the Audio System
The mistake: Treating the switch as IT's problem and the audio as yours. An unmanaged switch gets dropped in because it had enough ports, or the AV devices get patched into the general building VLAN alongside printers and guest Wi-Fi. The system passes commissioning and then develops intermittent clicks three weeks later that nobody can reproduce on demand.
What works instead: Spec the switch as audio equipment, with the settings written into the submittal — not left to whoever racks it. The list is short and it is not negotiable.
| Setting | Requirement | Why it matters |
|---|---|---|
| Energy Efficient Ethernet (802.3az) | Disabled | Port power-saving introduces jitter that clocks cannot track — the single most common cause of random dropouts |
| QoS / DiffServ | Enabled, DSCP trusted | Dante marks PTP events DSCP 56, audio DSCP 46; a switch that ignores marking will drop clock packets under load |
| IGMP snooping | Enabled, with a querier on the VLAN | Without a querier, multicast floods every port; with snooping off, multicast becomes broadcast |
| Spanning tree on device ports | Edge / portfast | A 30-second STP listening delay reads as a device that never comes back after a reboot |
| Switching capacity | Non-blocking, gigabit to every endpoint | Oversubscribed backplanes buffer, and buffering is jitter |
| VLAN | Dedicated AV VLAN | Keeps discovery traffic contained and keeps the audio off the path of a building-wide broadcast storm |
On any project where the client has an IT department, get those six lines in front of them at design, not at commissioning. It is a fifteen-minute conversation in July and a two-week standoff in November. The same principle applies to the physical layer — the structured cabling plant has to be Cat6A on any run that also carries PoE, both for bandwidth headroom and because bundled PoE cable heats itself and Cat6A dissipates it better.
Latency Is Real, and It Is Almost Never Your Problem
The mistake: Rejecting networked audio because "digital adds delay," then spending the savings on a problem that doesn't exist.
What works instead: Put the numbers against the actual tolerance. Broadcast practice holds audio within roughly 15 ms ahead of picture and 45 ms behind it before a viewer perceives a lip-sync error. A Q-LAN or Dante path contributes 1–4 ms. The display in the room is contributing 20–40 ms of its own processing, and a soft codec on a laptop contributes far more than either. Network transport is not where your latency budget goes.
Where latency genuinely matters is live reinforcement with performers on in-ear monitors, or any system where a listener hears both the acoustic source and the reinforced one. In those rooms you tighten the transport setting, keep the hop count low, and — more importantly — you deal with the loudspeaker delay alignment, which is measured in tens of milliseconds and dwarfs anything the network does.
Processing Moved to Software, and So Did the Risk
This is the change with the least discussion and the most operational consequence. In a fixed analog rack, the configuration lived in the hardware. In Q-SYS, the entire system — signal flow, DSP, control logic, touchscreen layouts, scheduled events, third-party device drivers — is a single design file, and the Core is a general-purpose computer running it.
The mistake: Treating that design file as the integrator's private property, or storing the only copy on the laptop of whoever commissioned it. When that person changes jobs, the client owns hardware they cannot modify.
What works instead: The as-built design file, the firmware version it was compiled against, and a written IP schedule are client deliverables, handed over at closeout and versioned. Firmware matters more than people expect: a design compiled under one Core firmware version will refuse to run on a mismatched one, so "we updated the Core over the weekend" is a genuine way to take a building's audio down. Update the design and the firmware together, in a maintenance window, with the previous version archived.
Where the Money Actually Moves
Networked audio does not make a system cheaper line for line. It moves cost from labor and conduit to devices and network infrastructure. On a multi-zone hospitality project — the pattern behind most of the venue work we do, including multi-floor club and hospitality builds — the shift looks like this:
- Down: Speaker cable footage, conduit fill, the number of home runs crossing the building, and the size of the central rack.
- Down: Change-order exposure. Adding a zone in year two is a network drop and an endpoint, not a new analog run through finished ceilings.
- Up: Managed switches, UPS for the network closet, and a real IP addressing scheme.
- Up: Endpoint count — networked amplifiers and interfaces distributed through the building instead of one central amp rack.
- Up: Commissioning time, because the system is now genuinely programmable and the control layer has to be designed rather than wired.
The net on a greenfield multi-zone build usually favors networked audio, and the gap widens every time the client changes their mind about a zone. On a single-room retrofit with four speakers and a wall plate, it does not — and that is worth saying plainly.
When Analog Still Wins
A single conference room with a display, a soundbar and a table mic does not need a Core. Neither does a two-zone patio. If the room has one source, one destination and no future, a fixed-function processor or a good powered mixer is the honest answer, and we will tell you so — the same way we say it about conference rooms that get over-specified. The threshold where networked audio starts paying for itself is roughly four or more independently controlled zones, or any project where the zone count is likely to change.
Where to Start
If you are scoping a system now, three questions settle most of the architecture. How many zones need independent source and level control, today and in five years? Is there a managed switch and a network closet with conditioned power, or does that have to be built? And who will own the system configuration after handover — because that answer decides whether you get a deliverable or a dependency.
Handsome Group designs and commissions networked audio systems across Los Angeles — restaurants, bars, hotels, clubs, houses of worship and corporate campuses — and we hand over the design file, the IP schedule and the as-builts as a matter of course. If you have an aging DSP rack and are trying to work out whether to repair it or replace the architecture, that is a conversation worth having before the next failure, not after. Our write-up on commercial audio system design for restaurants covers the zoning side of the same question.