AES67

An AES67 sender places digital audio samples into RTP packets for delivery across an IP network. A compatible receiver reconstructs the samples and plays them at the required time. The devices need agreement on parameters such as sample rate, channel format, packet timing and network addressing. Support for the standard creates a shared transport framework, but it does not remove the need to compare the actual capabilities of the two products.

Precise timing is provided through a supported PTPv2 configuration. Devices must share the appropriate clock domain and compatible profile settings, with network conditions that allow stable synchronisation. A receiver also needs a description of the intended stream, often supplied through SDP information. The mechanism used to discover, publish or load that description can vary between manufacturers, so routing may involve tools outside the AES67 transport specification.

• Identify the sender and receiver capabilities, not just the presence of an AES67 logo.
• Match the supported audio format, sampling frequency and packet-time combination.
• Verify PTP configuration and clock status before troubleshooting the programme content.
• Confirm the stream address, channel mapping and receiver subscription method.

Studios, broadcast facilities and live productions may contain equipment from several audio networking ecosystems. A defined interoperability mode can let compatible devices exchange audio without adding an analogue conversion simply to cross that boundary. This can preserve a digital path and expand connection choices. The benefit is strongest when the design documents both the transport settings and the control steps required at each end.

Interoperability is not the same as identical behaviour. One device may offer a convenient routing matrix within its own ecosystem but require manual stream information for an external receiver. Metering, device names, redundancy and remote control may not cross the boundary with the audio. Treat every additional feature as something to verify rather than a consequence of basic AES67 support.

BarCoe Studios debuted the UAE's first fully AES67-connected Dolby Atmos studio, built around Neumann and Merging Technologies. The wider production context is discussed in the Dolby Atmos music mixing article; that studio example should not be read as a guarantee that unrelated network products will connect without engineering checks.

Multicast is common in AES67 deployments and requires deliberate switch configuration. IGMP snooping can limit unnecessary traffic to ports that need it, but an appropriate querier and a coherent network design are important for stable membership management. Size the network for the actual stream count, packet overhead and traffic patterns rather than estimating only from the number of audio channels.

A Dante networking device with AES67 support may need that mode enabled, and not every product supports the same combinations of settings. Consult the specific product documentation for clock relationships, supported stream direction and channel limits. Native ecosystem routing and interoperable stream reception may appear in different configuration tools, even when both carry the same source material.

Imagine an Abu Dhabi production room that needs to send a stereo programme mix from one network audio system to a compatible recorder in another. The engineer first confirms that both products support a common AES67 configuration. The programme is routed to a dedicated stream, its session description is supplied to the recorder, and the receiving channels are assigned to the intended recording tracks.

1. Check the documented format and timing requirements on both endpoints before creating a stream.
2. Establish stable PTP synchronisation and verify the relevant network interfaces and addressing.
3. Publish or export the stream information, then configure reception using the supported method.
4. Record a test containing speech, music and clear channel identification, and replay it before the session.

The test must establish more than the presence of sound. Left and right identification, level, continuous playback and recording continuity all matter. If the recorder receives audio but cannot control the source device, that may be normal: AES67 transport does not automatically provide remote preamp control. A written handover should preserve the exact settings needed to rebuild the connection later.

The most expensive assumption is that compliant endpoints require no configuration. Devices can each support AES67 while using different current defaults. Likewise, clock lock does not prove the receiver has joined the correct stream, and a visible stream does not prove that its channel format is supported. Troubleshoot timing, transport, session information and local patching as separate layers.

• Do not equate AES67 with automatic discovery or a universal graphical controller.
• Avoid assuming that a redundant transport scheme in one ecosystem extends to another.
• Do not enable multicast traffic across an unmanaged production network without considering its effect.
• Record configuration changes so a later firmware update or reset can be assessed against a known working state.

For intermittent problems, inspect network counters, clock status and receiver error reports alongside listening tests. Increase observation time to cover the intended session pattern, including recording starts and stops where relevant. Replacing an audio cable cannot resolve an unsupported packet format, just as editing a session description cannot repair a damaged Ethernet connection.