Free forever·no account, no tracking, no third-party requests ·open data, free API
showstack / compare / dante-vs-aes67

Dante vs AES67

Can Dante and AES67 talk to each other? Below is every field we hold on both, side by side. Each one is sourced on the individual entry, and anything nobody could source is left blank rather than guessed.

Side by side

DanteAES67
Categoryaudio-transportaudio-transport
FlowMedia — large, continuous, on time and in orderMedia — large, continuous, on time and in order
PortsUDP 4321, UDP 4440, UDP 4444, UDP 4455, UDP 8700UDP 5004, UDP 9875
Transportudp, tcpudp
Multicast239.255.0.0/16 (Dante audio and video flows), 239.69.0.0/16 (AES67 flows from Dante devices), 224.0.0.230-233 (control and monitoring)yes
Spec availabilityproprietary-closedpublished-paid
StewardAudinate Pty LtdAudio Engineering Society (AES)
First published—2013
Statuscurrentcurrent
Our confidenceverifiedreported

Both are media flows. Anything that starves the link — usually a management transfer nobody scheduled — and jitter that outruns the receive buffer. That applies equally to either, so it is not a discriminator here.

What each one carries

Capability defined by the specification, not by any one product. A blank means the specification does not fix it, which is itself the answer on a transport like SRT.

DanteAES67
Sample rates44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, 176.4 kHz, 192 kHz48 kHz
Audio bit depth16-bit, 24-bit, 32-bit16-bit, 24-bit
Audio encodingLinear PCMLinear PCM, L16 and L24

Dante, audio: Channel count is a property of the device rather than of the protocol. Higher sample rates halve or quarter the channels a given device carries, which is the trade people meet when they switch a rig to 96 kHz.

AES67, audio: 48 kHz is the mandatory interoperability point; other rates may be supported but cannot be assumed between vendors. The same applies to packet time, where 1 ms is required and 125 microseconds is optional.

Speaks both (31)

These are the safe choices if you have not committed to either, or need to bridge the two.

Dante only (15)

AES67 only (2)

What goes wrong with Dante

Dante's own clock is PTP version 1 (IEEE 1588-2002). AES67 and ST 2110 use PTPv2. Putting a Dante device into AES67 mode moves it to a different clock domain, and the two do not share a grandmaster without a bridging device.
Energy Efficient Ethernet (IEEE 802.3az, sold as "green ethernet") must be disabled on every port carrying Dante. Audinate names it as a cause of clock instability and occasional dropouts, and it is on by default on cheap switches.
QoS has to be strict priority queueing, not weighted. Audinate's scheme is DSCP CS7 for PTP event messages, EF for audio and PTPv2, CS1 for reserved. A switch doing weighted fair queueing will still drop audio under load.
Discovery is mDNS on 224.0.0.251, which is link-local and does not cross a router. Devices on a different subnet will not appear in Dante Controller unless you are running Dante Domain Manager.
Multicast flows need one IGMP querier elected per VLAN. Two queriers, or none, and the flows either flood every port or vanish after the group membership times out.
There is no published wire specification. Anything that speaks Dante does so with a licensed Audinate module, chip or software stack, so "we will just write a driver" is not an option on this one.

What goes wrong with AES67

AES67 mandates no discovery method at all. SAP, Bonjour/mDNS and NMOS IS-04 are all in the field. Two fully compliant devices can sit on the same switch and never see each other, and you patch by hand from the SDP.
It standardises the stream and the clock, not the ecosystem. There is no AES67 device control, no level control, no naming, no subscription model, so day to day patching still happens in each vendor's own tool.
AES67 is built on PTPv2 (IEEE 1588-2008). Dante's native clock is PTPv1, so a Dante device switched into AES67 mode changes clock domain and stops clocking with its non-AES67 neighbours.
A 1 ms packet time is the only one every AES67 device must support. 125 us, 250 us, 333.33 us and 4 ms are optional, and broadcast gear often defaults to a short one for latency. A receiver that only does 1 ms just refuses the stream.
An AES67 flow carries no channel names. Channel order in the stream is the only thing that identifies what is where, so document the map or you will be counting pairs at soundcheck.

Sources

Disagree with any of this?

Every claim above comes from one of the two entries and carries a source. If one is wrong, correcting it is a single file and it fixes this page automatically. Edit Dante or edit AES67.