Dante, AES67, and ST 2110: What Matters Onboard

A concise reference note explaining Dante, AES67, and SMPTE ST 2110 for yacht teams that encounter IP media, broadcast-grade systems, or networked audio interoperability.

Dante, AES67, and SMPTE ST 2110 are often grouped together because they all sit in professional media-over-IP discussions. They are not equivalent. Dante is a widely used media networking platform, AES67 is an audio-over-IP interoperability standard, and ST 2110 is a professional media suite for video, audio, and ancillary data over managed IP networks.

On yachts, the practical issue is not the terminology. It is whether the chosen devices, firmware, licenses, clocks, network switches, multicast rules, QoS settings, and support owners have been proven together. A device claiming support for one standard may still need a specific mode, license, sample rate, PTP profile, firmware version, or vendor setting before it works in the installed system.

• Dante: An Audinate media networking platform commonly used for professional audio routing, device discovery, and control.
• AES67: An interoperability standard for high-performance audio-over-IP between systems that may otherwise be from different ecosystems.
• ST 2110: A SMPTE suite for professional video, audio, and ancillary data over managed IP networks.
• PTP: Precision Time Protocol, used where media endpoints need a shared timing reference.
• QoS: Quality of Service markings and switch behaviour that prioritise time-sensitive media traffic.
• Clock domain: The group of devices sharing timing; instability here can appear as clicks, dropouts, silence, or failed subscriptions.

• Dante between DSP, amplifiers, audio consoles, microphones, DJ interfaces, conference systems, or event racks.
• AES67 when one vendor ecosystem must exchange networked audio with another.
• ST 2110 or ST 2110-adjacent requirements for broadcast, production, large event, or high-end video workflows.
• Q-SYS, Dante, AV-over-IP, or broadcast systems that require specific DSCP/QoS treatment.
• Integrator drawings that mention multicast, PTP, boundary clocks, media VLANs, or clock master priority.

1. Confirm exact support: Check model, firmware, license, mode, sample rate, channel count, and vendor limitations. Do not assume family-level support applies to the installed device.
2. Define the clock plan: Record clock master, fallback behaviour, PTP domain/profile where relevant, reboot behaviour, and how clock faults are visible to crew.
3. Review network policy: Confirm VLAN, multicast, QoS, IGMP, uplink capacity, and whether discovery or media traffic crosses routed boundaries.
4. Test the actual signal path: Send a real source to the intended destination, fail and restore it, then record working settings, screenshots, and device versions.
5. Assign support ownership: Identify who owns the DSP file, switch config, clocking plan, firmware, and vendor escalation if the mixed path fails under guest pressure.

AES67 and ST 2110 can support interoperability, but they do not remove the need for device-specific testing. Treat every cross-vendor path as a formal acceptance test with evidence.