Why Was AES67 Developed?

Audio over IP solved a physical cabling problem and created a commercial one. Instead of running hundreds of analog or AES3 circuits, an installation could route channels over Ethernet with low latency, flexible capacity, and software-defined connections. The benefit was obvious, but the first generation of protocols was largely proprietary.

Native ecosystems controlled the whole user experience. A controller discovered devices from the same brand, arranged their channels, managed clocking, and presented one coherent workflow. That integration was powerful inside the ecosystem and restrictive outside it. Direct interoperability often required a bridge or a dedicated conversion device.

The result was vendor lock-in by architecture rather than by contract. Once a facility standardized on a console, stage box, amplifier, or processing platform from one ecosystem, replacing one layer could force changes across the rest of the signal chain. Users wanted the benefits of IP without accepting a permanent single-vendor boundary.

AES67 is powerful partly because it does not attempt to standardize every part of an audio network. It leaves discovery, connection management, security policy, device naming, and redundancy to existing ecosystems or higher-level systems. That choice allows native platforms to keep their strengths and lets vendors implement AES67 without rebuilding their entire product architecture.

The tradeoff is that two AES67 devices may carry audio successfully while offering completely different user experiences. One may advertise streams automatically, one may depend on a controller, and a third may require manual session descriptions. This is why integration projects need a control-plane inventory as well as a stream inventory.

The standard also does not guarantee audio quality by itself. It defines how PCM audio is transported and synchronized, not how a microphone is placed, how a converter performs, or how a network is tuned. Interoperability and sound quality are related but separate engineering responsibilities.

The strongest evidence of AES67's value is that interoperability became an expected product attribute. Major AoIP ecosystems now describe their relationship to AES67, and many products expose an interoperability mode rather than treating competing protocols as a complete barrier.

This changed competition from simple protocol exclusion to implementation quality. Vendors can compete on latency, channel density, control, redundancy, conversion quality, form factor, support, and integration depth while still offering a common audio path. Customers gain leverage because a single device no longer has to be replaced simply to connect one new subsystem.

AES67 also helped prepare the industry for ST 2110. Broadcasters wanted audio transport that could participate in an all-IP production architecture, and the AES67 body of work provided an important technical foundation for ST 2110-30. The standards remain distinct, but their shared assumptions made the transition easier.

Integrators gain a defensible way to connect mixed equipment. They can preserve a working native network, introduce a new vendor for a specific function, or create a migration path without replacing every endpoint at once. The audio transport can be standardized while the control and operational layers evolve on a separate schedule.

System owners gain bargaining power and lifecycle flexibility. A standards-based boundary makes it easier to compare products, retain useful legacy equipment, and replace one subsystem without rewriting the complete signal chain. It also creates a clearer test surface for acceptance and troubleshooting.

Those benefits depend on disciplined design. AES67 interoperability does not eliminate the need to document SDP sessions, multicast addresses, PTP domains, QoS policy, naming conventions, and support ownership. The standard provides the contract. The project team still has to make the contract operational.

For an OEM, AES67 can reduce the cost and time required to connect a product to a broader professional audio market. Instead of building a complete native ecosystem, a manufacturer can implement a defined interoperability path and concentrate investment on its own differentiation: DSP, acoustics, conversion, industrial design, reliability, or workflow.

The standard also gives product teams a shared test vocabulary. An OEM can specify supported sample rates, packet sizes, channels, PTP behavior, and stream-description handling, then test against representative third-party devices. A clear compatibility matrix is more useful than a general claim of AES67 support.

The commercial opportunity is strongest when the product fits a specific role in a hybrid system. A network bridge, stage interface, amplifier, processor, or recorder can add value by behaving predictably at the AES67 boundary while offering a differentiated native feature set above it.

AES67 does not make discovery and control universal, and it does not guarantee that every native feature can cross a vendor boundary. Meters, presets, gain sharing, redundancy state, device identity, and firmware workflows may still be proprietary. A successful integration plan must state which functions are audio streams and which remain outside the standard.

It also does not protect a poorly designed network. Incorrect QoS, uncontrolled multicast, unstable PTP, insufficient switch buffers, and weak monitoring can defeat an otherwise compliant implementation. Engineers should treat interoperability testing and network commissioning as one process.

Finally, AES67 is not a guarantee of future investment protection by itself. It is a durable standard foundation, but longevity also depends on product support, documentation, spare parts, security updates, and the willingness of vendors to maintain their interoperability modes. Standards reduce risk when the surrounding engineering and commercial commitments are sound.