Dante vs. AES67: What Is the Difference?

Spec sheets for networked audio gear often list both Dante and AES67, which makes them look like competing choices. They are not the same kind of thing.

• Dante is a proprietary audio-over-IP system from a single vendor: a hardware/software platform with its own discovery, naming, routing, and control software. Devices that carry it are licensed implementations of one company's design.
• AES67 is an open interoperability standard published through the Audio Engineering Society standards program. It does not define a product or a control application. It defines the minimum set of transport and timing behaviors two systems must share to exchange uncompressed audio streams over an IP network.

So the honest comparison is not "which is better" but "what does each one cover."

What AES67 specifies

AES67 draws on existing IETF and IEEE work rather than inventing new mechanisms. Its core requirements are narrow and deliberate:

• Clocking — synchronization using IEEE 1588 Precision Time Protocol, so independently clocked devices share a common notion of time.
• Transport — linear PCM audio carried in RTP packets, with a required common baseline of 48 kHz sampling and small packet times so that any two conformant devices can find a format both support.
• Session description — stream parameters published in SDP, so a receiver can learn channel count, format, and timing for a stream it did not create.

What AES67 deliberately leaves out is nearly everything a user interacts with: device naming, subscription management, presets, metering, firmware handling, redundancy schemes. Those live in the vendor layer.

What "AES67 mode" means on a device

A proprietary system and AES67 are not mutually exclusive. Many networked-audio products can expose some or all of their channels as AES67 streams while continuing to use their native system for everything else. That is what an "AES67 enabled" setting usually means: the device will originate and accept standards-conformant streams so that foreign equipment can connect.

Two practical consequences follow, and they are the ones that surprise people:

1. You usually lose the convenience layer. Automatic discovery and one-click routing are features of the proprietary platform. Across an AES67 boundary, stream setup is often manual or handled by a separate connection-management tool, because the standard does not mandate a single control method.

2. Channel counts and clocking get stricter. A vendor system can negotiate its own preferred packet sizes and sample rates internally; the AES67 path has to stay inside the profile both ends implement, and both ends have to agree on a PTP grandmaster.

Where this sits in the broader stack

AES67 is also the audio layer other standards point at rather than duplicate. In the SMPTE ST 2110 suite for professional media over managed IP networks, the audio part — ST 2110-30 — carries PCM audio by reference to AES67 rather than defining a separate transport. That is why a broadcast facility can describe its audio as "ST 2110-30" and its installers can still talk about AES67 streams. We cover that relationship in AES67 and SMPTE ST 2110-30.

Reading a spec sheet

Useful questions when a datasheet claims both:

• Are AES67 streams available on all channels, or a fixed subset?
• Is the device able to act as a PTP leader, or does it require an external clock?
• Which packet times and channel groupings are supported — the baseline only, or more?
• Is stream setup done in the vendor's software, in a separate connection manager, or by static configuration?

And for the older point-to-point wiring these systems often replace or coexist with, see what AES3, AES67, and BS.1770 mean on a spec sheet.