Dante and AES67

AES67 is maintained as a public standard. Its purpose is to define a common interoperability surface that many manufacturers can implement without adopting one company's controller, discovery model, or product family. Dante is a commercial technology ecosystem owned and developed by Audinate. It provides a complete user experience across discovery, routing, clocking, device management, virtual soundcards, software, and certified hardware.

That difference is not a defect in either model. A standards body can define a durable common layer but cannot guarantee the user experience of every implementation. A commercial ecosystem can deliver tightly integrated tools and predictable behavior but remains under the control of its owner.

Dante AES67 interoperability is therefore best viewed as a meeting point between those models. Dante devices may expose selected streams in an AES67-compatible form, and AES67 devices may be able to receive or send those streams. The rest of the Dante workflow remains Dante-specific.

AES67 is developed through AES standards activity. Dante and the associated names, logos, and technical specifications are controlled by Audinate. A product that supports Dante AES67 interoperability is not thereby open-sourced, nor does an AES67 implementation become a Dante product by definition.

Trademark accuracy matters in technical writing. Use Dante only to describe Audinate's technology and use the manufacturer's official product names when referring to a specific device or mode. Avoid implying that AES67 owns Dante or that Dante is a generic synonym for AoIP.

Dante is a trademark of Audinate Pty Ltd. This page is an independent technical comparison.

Trademark attribution is editorial context, not a substitute for reviewing the supplier's current terms.

Native Dante devices are commonly discovered through the Dante control ecosystem and managed with tools such as Dante Controller or Dante Director, depending on the product and deployment. The user sees device names, channel labels, subscriptions, clock status, and diagnostics in a unified interface.

AES67 does not define one universal discovery or routing protocol. When Dante operates in an AES67 interoperability mode, the audio stream may be visible to an external system through a session description or a compatible discovery mechanism, but this does not mean that every Dante feature becomes available in the external controller.

Integrators should document two layers: the audio flows that cross the AES67 boundary and the management actions that remain native. A useful hybrid diagram shows Dante Controller on one side, the AES67 device or controller on the other, and the exact points where SDP, multicast addresses, PTP configuration, and channel mapping are exchanged.

Dante uses its own clocking model and offers configurable latency settings for native flows. AES67 mode may impose a different packet-time or latency setting because the interoperability contract must match the external device. A successful design should use the same sample rate, packet time, and clock relationship on both sides of the connection.

Latency is not a single number. It includes packetization, receiver buffering, device processing, network transit, and any conversion between native and interoperability modes. The safest comparison is end-to-end latency measured in the real topology, not the lowest setting printed on a datasheet.

Dante provides redundancy options within its ecosystem, while AES67 itself does not define one universal seamless protection mechanism. A hybrid deployment may preserve native redundancy inside the Dante domain while exposing a different protection model at the AES67 boundary. The failure behavior of that boundary must be tested and documented.

PTP alignment is equally important. Dante devices and AES67 devices may need to share a clock reference or bridge between timing domains in a controlled way. Poor PTP planning can produce intermittent audio even when routing and bandwidth appear correct.

Native Dante management covers more than audio subscription. It includes device naming, channel labels, clock monitoring, firmware workflows, event logs, and access to Audinate services or software. AES67 interoperability mode does not automatically expose those management functions to a third-party system.

A hybrid project should define who owns each layer. Who assigns Dante device names? Who owns AES67 multicast addresses? Who monitors PTP? Who receives alarms if a stream disappears? Who updates firmware on each side of the boundary? Ambiguous ownership is a common cause of slow fault resolution.

Support boundaries should be explicit as well. A vendor may support the Dante device, the AES67 mode, and the network configuration separately, while refusing responsibility for a third-party controller or a non-standard switch design. A written integration matrix reduces finger-pointing during commissioning and operations.

Dante products participate in Audinate's product and certification program, and the available feature set can vary by device class, hardware, firmware, and license. AES67 support should be verified against the exact model and firmware release rather than inferred from the Dante brand.

A useful compliance review asks four questions. Does the device support the required AES67 stream direction? Does it support the sample rate and packet time? Does it expose the necessary channel count? Does its clock and redundancy behavior fit the system design? A fifth question is whether the vendor documents the limitations of interoperability mode.

Certification is evidence about a specific tested configuration, not proof that every combination will behave identically. Keep the firmware version, configuration export, test scripts, and measured results with the project record.

In a typical Dante AES67 deployment, selected transmit or receive flows are configured to use an AES67-compatible transport and timing relationship. This can allow a Dante network to feed a non-Dante processor, broadcast device, recording system, or another AoIP platform that supports the same interoperability profile.

The boundary is usually narrower than the native workflow. An AES67 receiver does not necessarily know the Dante device name, channel labels, or subscription model. It may only see an IP stream described by SDP. Conversely, the Dante controller may not be able to manage every property of the external receiver.

Some features may also change when a device leaves native Dante mode. Channel counts can be lower, latency settings may be limited, sample rates may be constrained, and redundancy behavior may differ. Those limitations are implementation-specific and should be confirmed in the current product documentation.

The biggest limitation is not always bandwidth. It is operational visibility. A Dante operator may see a healthy native network while an AES67 cross-connection has failed, or an AES67 controller may show a stream without knowing that its Dante source has entered a degraded native state. Cross-domain monitoring is essential.

Multicast design is another common risk. Dante, AES67, and the surrounding network may have different conventions for address allocation, IGMP behavior, and stream density. A clean multicast plan should reserve ranges, limit group membership, and verify querier behavior on every VLAN.

Finally, a Dante AES67 connection is not a universal converter for every format or control feature. It does not turn non-audio signals into audio, replace a sample-rate converter, or guarantee that a third-party device can control a Dante product. Those functions require separate products or management integration.

A pure Dante deployment is usually the simplest option when every critical endpoint comes from the Dante ecosystem and the project values one controller, one support model, and predictable native features. Adding AES67 to a clean Dante system can introduce clock, multicast, and testing overhead that the project does not need.

A hybrid deployment makes sense when a facility must connect a Dante estate to a RAVENNA system, an ST 2110-30 production core, a third-party processor, or a standards-based recording or monitoring platform. It also makes sense during migration, when a site wants to introduce a new subsystem without replacing the existing Dante network.

The practical design question is not pure versus hybrid in the abstract. It is which flows need to cross the boundary and what guarantee each flow requires. A small number of low-risk monitor streams may tolerate a simple bridge. A live broadcast path may require redundant networks, deterministic timing, monitoring, and a tested failure procedure.

Start the checklist with stream requirements: direction, sample rate, packet time, channel count, multicast or unicast, and expected recovery behavior. Then verify Dante model, firmware, license, interoperability mode, PTP configuration, redundancy support, and management visibility. Test the exact pair of devices, not only the marketing category.

A common misconception is that AES67 support makes a Dante device generic. In practice, native Dante behavior remains the center of the product experience. Another misconception is that AES67 mode is always free or always identical across models. Licensing, hardware, firmware, and product class can all affect availability.

A third misconception is that interoperability is only an engineering detail. It changes procurement, operations, support, and training. The best hybrid design gives each ecosystem a clear role and creates a narrow, documented boundary with measurable acceptance criteria.

• Confirm the exact Dante model and firmware release.
• Verify AES67 direction, channel count, and packet format.
• Document the PTP and clock boundary.
• Decide how multicast, redundancy, and monitoring will work.
• Test recovery before the system is commissioned.