In a modern OB truck or radio station, dozens of devices exchange digital audio over a plain Ethernet network. A console at one end, stageboxes at the other, recorders, processors, sometimes video — all of it has to play the same sample at the same instant. What makes that miracle possible is not the cable or the audio protocol, but a shared clock distributed by the network itself. That clock is called PTP, and it is what holds the whole audio-over-IP edifice together.
Why clocking is vital in the digital domain
A digital audio signal only exists through its samples, taken at a steady rate — 48,000 times a second in broadcast. For two devices to exchange audio without artefacts, they must take and reproduce those samples at exactly the same rate. If one runs at 48,000 Hz and the other at 48,001 Hz, the gap accumulates: after a few seconds a sample “goes missing” or “appears”, and you hear a click. Across an entire network with no common reference, it is guaranteed chaos.
In classic digital, that reference was called word clock: a clock signal distributed over dedicated cables, in a star, from a master clock. It works, but it does not scale to an IP network where audio, control and sometimes video already share the same cable. Running a separate clock cabling alongside the data network would be absurd. Hence the idea: what if the clock travelled inside the network, with the data?
PTP: a clock that travels in the network
PTP (Precision Time Protocol, standardised as IEEE 1588) does exactly that. Instead of distributing a dedicated clock signal, it distributes the exact time through network packets, with sub-microsecond precision. Every device on the network locks to a single time reference and derives its sample rate from it. It is the common foundation of AES67 and SMPTE ST 2110; Dante, historically built on an earlier version, has migrated to PTP “version 2” for interoperability.
The mechanism rests on a constant dialogue. A reference clock, the grandmaster, broadcasts the time. Each device measures the round-trip time of the messages to estimate — and compensate for — the transit delay across the network. That delay compensation is what separates PTP from a simple time broadcast: the protocol does not just say “it is such-and-such a time”, it accounts for how long the message took to arrive.
Grandmaster, slaves and automatic election
On a PTP network, a single device is authoritative at any given moment: the grandmaster. The others lock to it. But who decides which one is in charge? The protocol provides an automatic election (the BMCA, Best Master Clock Algorithm): each clock announces its quality — its accuracy, its source, its rank — and the network picks the best. If the grandmaster fails, a new election is held and another device takes over, ideally with no audible dropout.
In a serious installation you do not leave that role to chance. You designate one or two dedicated grandmasters, often locked to an external reference — a GPS signal, for example — to guarantee an ultra-stable time base and, in television, sync between audio and video. You then set priorities so those grandmasters always win the election and consoles or stageboxes stay slaves. It is a principle you find across the broadcast chain, from the intercom network to signal distribution.
What breaks when clocking drifts
PTP is robust but sensitive to the infrastructure. The first enemy is the switch that does not understand time. An ordinary network switch introduces variable, unpredictable delays depending on its load; yet PTP needs stable delays to compensate correctly. Hence the use of “PTP-aware” switches (with a boundary clock or a transparent clock) that account for the time spent inside the device. On a poorly designed network you see the classic symptoms: devices “dropping” off the grandmaster, intermittent clicks, wandering sync, even total audio loss.
The other traps are more mundane: two misconfigured grandmasters fighting for authority, a saturated network where time packets arrive late, a badly planned VLAN segmentation that cuts some devices off from their clock. The golden rule: a network carrying audio-over-IP is not an office network. It is designed, sized and monitored like critical infrastructure — because that is exactly what it is.
One clock, several worlds
PTP’s great strength is unifying what used to be separate. The same protocol clocks a radio console’s audio, the ST 2110 streams of a TV studio and, via GPS, alignment with the traditional video world. It enables “distributed” architectures where processing resources live in a data centre rather than the control room, as long as the clock stays shared. Understanding PTP is understanding why audio-over-IP could replace point-to-point links: it is not just a matter of fatter pipes, but of a time reference common to all. For the rest of the IP chain, our overview of audio-over-IP and our guide to contribution codecs round out the picture.
My take
PTP is one of those subjects you hope never to have to open, because “when it works, you don’t see it”. That is exactly why you should understand it before the day it stops working. The move to IP has democratised architectures once reserved for big infrastructure, but it has shifted the skill: the weak link is no longer the converter, it is the network and its clock. The good news is that manufacturers have matured enormously on robustness and grandmaster failover. The question to ask before any deployment stays the same: is my network built to carry time, or only data? Everything else follows from that.
