Quick Answer
PTP is the timing layer used when millisecond-grade computer time is not enough. In broadcast and AoIP systems, it is there to keep devices aligned tightly enough for audio, video, and timing-sensitive transport. The exact behavior still depends on the profile, device support, and switch design.
Why typical Network Time fails
NTP (Network Time Protocol) is appropriate for keeping general-purpose computer clocks close to time of day, but it is not the media-clock mechanism used to align samples or video timing in these professional IP systems. At 48 kHz, one sample period is about 20.8 microseconds, so media devices need a shared timing architecture designed for that job.
PTP (Precision Time Protocol) provides that timing foundation in supported Dante, AES67, and SMPTE ST 2110 systems. Well-designed hardware-assisted networks can achieve very tight alignment, but the result depends on the selected profile, clock devices, timestamping, switches, topology, and load.
The BMCA (Best Master Clock Algorithm)
PTP clock datasets and profile rules are compared by the Best Master Clock Algorithm. Operators can influence or constrain selection through supported priority and device settings; the exact controls vary by profile and product.
- It checks clock quality (e.g., GPS-locked hardware vs a software clock).
- It checks priority settings (Priority 1 and Priority 2 vectors).
- It uses the remaining clock-identity fields as defined by the active PTP standard and profile when earlier comparison fields tie.
The selected clock provides the grandmaster reference. Ordinary-clock follower ports synchronize to it, while boundary and transparent clocks have different roles in distributing or correcting timing through the network.
Profiles, Transport, and Domains
IEEE 1588 supports multiple transports and lets industries define profiles with interoperable parameter sets. Layer-2 versus UDP/IP transport is separate from the question of which profile and domain the devices use:
- Dante and AES67: Clocking behavior and interoperability depend on the device mode, supported PTP version/profile, and vendor guidance. Do not infer compatibility from “PTP” alone.
- SMPTE ST 2110: Broadcast systems commonly use the SMPTE ST 2059-2 PTP profile. Its parameters and network design must be implemented as specified, not reduced to one message-rate rule.
How to Use It
When a system depends on PTP, check the profile, clock domain, switch behavior, and QoS model before patching media. Treat timing as infrastructure, not as an afterthought that will fix itself once audio or video starts moving.
Common Mistakes
If your devices are not syncing, start with these common failure points:
- Clock Domain Mismatch: devices must share the correct domain and timing profile.
- QoS or queue problems: timing packets need the switch behavior the system was designed for.
- Profile mismatch: not every PTP-capable device is using the same broadcast-oriented profile.
- Unsupported switch behavior: boundary, transparent, and multicast behavior still matter.