What is AES67?

Definition and revision context

AES67 is officially titled AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability. The Audio Engineering Society published the first edition in 2013 and issued the AES67-2018 revision after industry experience exposed ambiguities and integration details that needed clearer treatment.

The standard does not create a single closed ecosystem. It defines a technical meeting point where products from different vendors can exchange real-time audio when each product implements the required profile and the system integrator configures the shared network correctly. Compliance is therefore a starting point, not a promise that every optional feature or management function will work automatically.

For procurement and design work, cite the edition being used and verify the manufacturer's conformance statement. AES67-2018 is the revision most current procurement documents reference, but teams should still check the AES standards catalog for amendments, corrigenda, or later editions before freezing a specification.

The standard defines interoperability at selected layers. It does not standardize every operational behavior a user sees.

The interoperability problem AES67 solves

Before AES67, each Audio over IP platform solved similar problems in its own way. A Dante network, RAVENNA network, Livewire system, or Q-LAN installation could deliver excellent real-time audio inside its own product family, but direct cross-vendor routing often required bridges, conversion hardware, or manual workarounds.

That fragmentation created commercial and operational risk. A facility could become dependent on one ecosystem for routing, clocking, control, and support. Expanding the system meant checking protocol compatibility before evaluating acoustics, workflow, or price. Legacy equipment became harder to retain when a new platform arrived.

AES67 addresses that problem by specifying a common interoperability path for audio transport. It lets a native ecosystem expose selected streams in a form that another AES67-capable ecosystem can receive. This is why AES67 is often described as a bridge: it does not erase the differences between platforms, but it makes controlled movement between them possible.

Audio over IP fundamentals

An AoIP system converts sampled audio into time-stamped packets, sends those packets over Ethernet and IP infrastructure, and reconstructs a continuous audio signal at the receiver. The difficult part is not moving bytes. It is preserving sample timing, channel relationship, and playback continuity while sharing a packet network with other traffic.

AES67 assumes a managed network that can separate real-time media from ordinary data. Switches need sufficient buffering, multicast control, and traffic prioritization. Routers can carry streams between subnets when the design supports multicast routing or unicast flows, but every boundary adds configuration and monitoring requirements.

The media clock is separate from the packet clock. PTP aligns device time, while the audio sample rate defines the media clock. A receiver must recover both the correct sampling phase and a stable stream of samples. Packet loss, excessive jitter, or an unstable clock can produce dropouts even when the average network bandwidth is more than sufficient.

Treat network design as part of the audio system, not as supporting infrastructure. VLANs, QoS, PTP domains, multicast queriers, and switch buffering policies need to be validated together. For critical program paths, you should also define the degraded mode, alarm path, and recovery time after a failure.

• Sampling converts analog audio into discrete numeric values at a defined rate.
• Packetization adds sequence, timestamp, and payload information so receivers can reconstruct the stream.
• Buffering absorbs normal network variation but increases end-to-end latency.
• Synchronization keeps independent devices aligned to one shared time reference.

PTPv2, RTP, and SDP

AES67 uses IEEE 1588-2008 Precision Time Protocol, commonly called PTPv2, to distribute a common time reference. PTP messages allow devices to compare timestamps and correct for network delay. In audio systems, the resulting time base lets senders and receivers place samples on a shared timeline rather than relying only on local oscillator frequency.

Real-time Transport Protocol, defined in RFC 3550, carries the audio payload. RTP supplies sequence numbers and timestamps that allow receivers to detect missing or out-of-order packets and reconstruct the intended playback time. RTP Control Protocol can provide reception statistics, although control and monitoring choices vary by product.

Session Description Protocol describes the stream before it is received. An SDP document identifies media type, address, port, payload format, packet time, channel mapping, and other parameters. In some systems SDP is exchanged directly; in others it is carried by a discovery or management layer. Because AES67 does not define one universal device-control protocol, SDP handling can differ between implementations.

PTP, RTP, and SDP are standards used by AES67. They are not optional marketing labels.

QoS, PCM, and multicast behavior

AES67 uses linear PCM audio so receivers do not need a proprietary codec to interoperate. The common payload forms are 16-bit and 24-bit PCM, often described by RTP payload types such as L16 and L24. A sender and receiver must agree on sample rate, packet time, payload type, channel count, and channel ordering.

Quality of Service matters because audio packets are delay-sensitive but not necessarily high in bandwidth. DSCP markings and queue treatment give PTP and RTP traffic priority over file transfers, backups, and general office data. A VLAN can help separate media traffic, but VLAN separation alone is not a substitute for proper queue design and monitoring.

Multicast lets one sender distribute a stream to several receivers without duplicating traffic for every endpoint. It also introduces risks: misconfigured IGMP snooping, absent queriers, or accidental flooding can disrupt the whole network. Large deployments should plan multicast address ranges, querier placement, group limits, and PTP domains before commissioning.

After go-live, packet loss, jitter, PTP offset, IGMP state, and switch queues need continuous observation. Many interoperability problems do not show up as complete silence, but as intermittent dropouts, swapped left and right channels, failure to recover after a restart, or anomalies that appear only under higher load. Observability should be designed together with the audio path.

• Reserve capacity and queue budgets for media traffic.
• Use a documented multicast address plan.
• Verify PTP domain and priority settings across all switches.
• Monitor packet loss, jitter, clock offsets, and IGMP state after deployment.

What AES67 does not define

AES67 does not prescribe one automatic device discovery system. Some products use SAP announcements, some use mDNS or Bonjour, and some rely on a native controller or a third-party orchestration tool. A device can be AES67-capable and still require manual SDP exchange or vendor software to establish a connection.

It also does not define a universal connection-management model, a mandatory user interface, or a complete security architecture. Routing permissions, naming conventions, firmware updates, access control, and monitoring APIs remain product-specific. This is one reason AES67 interoperability often works best when a controller or management layer above the audio transport can coordinate endpoints.

Redundancy is another important boundary. AES67 defines the streaming and synchronization layers, not seamless packet duplication or switchover. Systems that require hitless redundancy commonly add a network redundancy scheme from the surrounding architecture, such as dual links with a media-specific protection method, and the exact behavior depends on the products and network design.

Finally, AES67 does not guarantee interoperability merely because a badge appears on a datasheet. The implementation still has to negotiate compatible parameters, support the required payload format, and behave correctly under the expected PTP and network conditions.

Dante, RAVENNA, and AES67 interoperability

Dante is Audinate's proprietary audio networking technology. Dante AES67 interoperability typically appears as a mode or configuration that lets selected Dante flows exchange audio with other AES67 devices. Native Dante discovery, routing, control, and management remain part of the Dante ecosystem, so an AES67 connection may coexist with a control plane that still requires Dante Controller or another Audinate tool.

RAVENNA is an open technology platform built around standard IP protocols and is strongly aligned with AES67 and SMPTE ST 2110-30. It can carry additional profiles, formats, channel counts, synchronization options, and redundancy models beyond the minimum AES67 interoperability contract. AES67 is therefore a common layer inside a broader RAVENNA deployment, not a complete description of every RAVENNA capability.

Hybrid designs are common. A facility may keep a native Dante estate for stage boxes, amplifiers, and consoles while using AES67 to connect a broadcast core, a RAVENNA production system, or a specific third-party processor. The integration plan should identify which endpoints are native, which are in interoperability mode, where SDP is exchanged, and who owns clock and multicast policy.

The most fragile part is often not whether audio can be sent, but how the boundary is maintained. Whether both sides still reconnect after a firmware upgrade, a device restart, a clock master switchover, or a network failure; whether alarms arrive in one place; and whether there is a clear maintenance procedure all need to be defined early in the project.

Interoperability mode is a system design choice. It does not erase native feature differences.

Deployment guidance

Start with a written signal and clock plan. List every stream, its direction, sample rate, packet time, channel count, multicast group, source address, receiver, and fallback path. Decide whether the network will use unicast or multicast for each class of traffic, and define how SDP will be conveyed and stored.

Build a PTP domain plan before adding endpoints. Confirm which devices can be grandmasters, how boundary or transparent clocks are handled, what happens if the preferred grandmaster disappears, and whether the network has a stable holdover strategy. Test PTP performance with the same switch configuration and traffic load expected in operation.

Then test interoperability as a system, not as a product demonstration. Confirm channel mapping, nominal gain, sample alignment, stream recovery after a link event, multicast join and leave behavior, and management visibility. Include edge cases such as firmware mismatch, a rebooted grandmaster, an unplugged receiver, and a congested uplink.

Commissioning should leave durable evidence: switch configurations, PTP logs, stream records, test results, and ownership for future changes. AES67 simplifies the transport contract, but it does not remove the need for professional network discipline.

SoundNet AES67 module solutions

Understanding the standard is one thing; shipping a product that speaks AES67 reliably is another. SoundNet's YW series OEM modules put a complete, production-tested AES67 implementation — PTPv2 clocking, RTP audio transport, and device discovery — into embeddable hardware, so professional audio manufacturers can add networked audio to their products instead of building the stack from scratch. The family scales from the compact 4×4 YW04d to the YWRG128 Mini-PCI module with up to 128×128 channels at 48, 96, or 192 kHz.

Around the modules sits a toolchain that covers the full workflow: the license-free AES67 LINK Controller for routing and configuration, the AES67 Virtual Soundcard for turning a PC into a 64×64 endpoint, the PoE-powered AES67 Panel for room control, and the open-source Stream Monitor for verifying multicast streams on a live network.

• Complete AES67 stack on module: synchronization, transport, and discovery are handled by the module, not by your firmware team
• Scalable from 4×4 to 128×128 channels over I2S/TDM interfaces at 48/96/192 kHz
• Optional on-module DSP with parametric EQ, filters, delay, noise gate, and feedback suppression
• One integration effort across the whole family, from small endpoints to high-density transport
• Finished-product tooling: LINK Controller, VSC, Panel, and Stream Monitor cover configuration, routing, and monitoring

Applications and common misconceptions

AES67 is used in broadcast facilities, houses of worship, conference centers, stadiums, performance venues, recording studios, and large campus installations. It is especially useful where equipment from several vendors must share audio, where an existing AoIP estate should connect to a new production core, or where a standards-based transport is required for long-term maintainability.

One misconception is that AES67 means every AES67 device can be controlled in the same way. In practice, audio may flow while discovery, routing, labels, and monitoring remain separate. Another misconception is that AES67 is a quality level or a codec. It is an interoperability framework; audio quality depends on the source, sample format, clocking, and network behavior.

A third misconception is that AES67 and ST 2110-30 are interchangeable names for the same standard. They are closely related, but AES67 is an AES audio interoperability standard while ST 2110-30 is a constrained audio component of SMPTE's broader professional media over IP suite. Some technical documents write ST2110 without the space when naming the family. The distinction matters when specifying broadcast workflows, NMOS control, PTP profiles, and conformance levels.

Finally, AES67 is not a button that automatically solves every compatibility question. Product support scope, available options, licensing, firmware state, network design, and operational procedures all influence the outcome. Writing the boundaries down clearly and running end-to-end acceptance tests is more reliable than relying on badges or marketing claims.