Time Sync Protocols — PTP and NTP for AV

Networked audio and video systems depend on precise clock synchronization to function correctly. Dante, AES67, SMPTE ST 2110, and broadcast video-over-IP all require sample-accurate timing alignment across devices that may be hundreds of meters apart. Two protocols handle this: IEEE 1588 PTP for microsecond-precision AV applications and NTP for general IT clock synchronization.

Why Clock Sync Matters in AV

In analog systems, all devices share the same physical word clock signal distributed over coaxial cable. Every device locks to the same reference, keeping samples aligned.

In networked audio, devices are physically separated and connected through switches. Without a common clock reference, each device runs on its own oscillator — and oscillators drift. Even a few parts per million of drift, when multiplied across thousands of audio samples per second, causes audio samples to go out of phase across devices, producing clicks, pops, dropped samples, or complete audio failure.

PTP solves this by distributing a single, highly accurate time reference across the Ethernet network with sub-microsecond precision. All networked audio devices lock to this reference, keeping their sample clocks aligned regardless of physical location.

IEEE 1588 PTP — Precision Time Protocol

IEEE 1588 PTP (Precision Time Protocol) is the time synchronization backbone for Dante, AES67, and SMPTE ST 2110. It achieves sub-microsecond accuracy on a well-configured network.

How PTP Works

PTP operates by having a Grandmaster Clock — the most accurate clock on the network — distribute time to all other devices (called Ordinary Clocks or Slaves). PTP compensates for network delay by measuring the round-trip time of synchronization messages and calculating the path delay.

The synchronization process:

1. Announce messages advertise each device's clock quality and identity
2. Best Master Clock Algorithm (BMCA) automatically selects the most accurate clock as Grandmaster
3. Sync messages carry the Grandmaster's timestamp
4. Follow_Up messages provide the precise send time of each Sync message
5. Delay_Req / Delay_Resp messages measure the path delay between Slave and Master

This measurement and correction cycle runs continuously, allowing Slave clocks to track the Grandmaster with sub-microsecond accuracy even as network conditions change.

PTP Profiles

Different industries use customized PTP profiles with specific settings for their requirements:

Dante uses a proprietary implementation based on IEEE 1588 with its own extensions. AES67 specifies the IEEE 1588-2008 profile with specific parameters for audio applications.

Grandmaster Clock Selection

By default, PTP devices run the Best Master Clock Algorithm (BMCA) to automatically elect a Grandmaster. The BMCA selects based on: clock class → clock accuracy → clock variance → clock identity (MAC address as tiebreaker).

In practice, automatic election works well in small, single-vendor Dante networks. Problems arise in:

• Mixed-vendor networks — different manufacturers' PTP implementations may have conflicting clock qualities, causing unstable grandmaster elections that result in clock "flip-flopping" and audio dropouts
• Large installations — many devices competing in BMCA can create slow or unstable elections
• Networks with multiple PTP domains — Dante and AES67 use different PTP domains; without careful configuration they can interfere

For critical installations, deploy a dedicated PTP Grandmaster appliance (from Meinberg, Endrun, or similar vendors) that provides GPS-disciplined timing with extremely high clock quality. This ensures the grandmaster is always stable and never changes.

PTP and Network Switches

Network switches affect PTP accuracy in two ways:

Transparent Clocks — A switch with PTP Transparent Clock support measures the time a PTP message spends inside the switch and adds that residence time to the message's correction field. This eliminates the variable queueing delay through the switch from the timing calculation.

Boundary Clocks — A switch with Boundary Clock support terminates PTP sessions on ingress ports and generates new sync messages on egress ports. Boundary Clocks are more complex to configure but provide excellent accuracy in large multi-switch topologies.

Non-PTP-aware switches — Most switches, including enterprise-grade managed switches, are not PTP-aware. They forward PTP packets like any other UDP traffic, but the variable queuing delay adds jitter to the timing measurements. For Dante and AES67, non-PTP-aware switches are generally acceptable — PTP's delay measurement compensates for consistent delays — but high-jitter switches degrade clock accuracy. Choose switches with consistent low-latency forwarding for AV networks.

NTP — Network Time Protocol

NTP (Network Time Protocol, RFC 5905) is the standard for synchronizing computer clocks over IP networks. It provides millisecond-level accuracy — far less precise than PTP's microsecond level, but sufficient for general IT purposes.

AV uses for NTP:

• Timestamping log entries on control processors and DSPs
• Ensuring AV control systems display the correct time for scheduling
• Certificate validation in TLS-secured AV API connections
• Coordinating scheduled events across AV control systems

NTP does not replace PTP for audio or video synchronization. Dante, AES67, and SMPTE ST 2110 require PTP. NTP is for IT-level clock management — keeping the web GUI clock correct, log timestamps, and scheduled events.

NTP Architecture

NTP uses a stratum hierarchy. Stratum 0 is the reference clock (GPS, atomic clock). Stratum 1 servers are directly connected to Stratum 0. Stratum 2 servers synchronize to Stratum 1, and so on. Public NTP pools (pool.ntp.org) provide Stratum 2–3 servers accessible from the internet.

For AV control systems:

• Configure the control processor to use the building's NTP server or a public NTP pool
• Ensure AV VLANs allow UDP port 123 outbound (NTP) if devices need internet NTP access
• For air-gapped or isolated AV networks, deploy an internal NTP server (many routers and domain controllers serve NTP)

PTP vs. NTP Comparison

Common Pitfalls

• PTP grandmaster instability on mixed-vendor networks — When Dante devices and AES67 devices both run BMCA on the same network, clock elections can become unstable. Different vendors may have different default clock priorities, causing the grandmaster to switch between devices and producing brief audio dropouts. Use a dedicated grandmaster or carefully configure clock priorities per vendor documentation.
• Using NTP-only for Dante clock sync — NTP's millisecond accuracy is thousands of times too coarse for audio sample synchronization. Dante uses PTP internally. Never try to substitute NTP for PTP in AV audio systems.
• High-jitter switches degrading PTP accuracy — A switch with high queuing jitter corrupts PTP timing measurements. This is less of a problem for Dante (which uses a proprietary PTP implementation with built-in compensation) but matters for AES67 and SMPTE ST 2110 with tighter accuracy requirements. Check switch specifications for port-to-port latency variation.
• Dante and AES67 on the same network without domain management — Dante uses PTP domain 0 by default; AES67 uses domain 0 as well. Without careful configuration, Dante and AES67 devices may compete for grandmaster, causing instability. In mixed-protocol environments, assign different PTP domains to each protocol and configure them not to interfere.
• Forgetting NTP on control processors — Control systems with incorrect clocks produce log entries with wrong timestamps, making troubleshooting difficult. Scheduled events that depend on the system clock (auto-startup sequences, scheduled reboot times) fail or run at wrong times. Always configure NTP on every control processor.