As previously covered in this column, IEEE 1588 Precision Time Protocol (PTP) is an essential part of a modern all-IP media production system. By distributing a highly accurate clock signal (to within a microsecond) to every part of a network, many good things can be made to happen: Cameras can be frame-accurately synchronized. Audio signals can be synced to each other and to video streams. Video signals can be switched at precise frame boundaries in the middle of a packet network. All this can happen with a simple common clock and an agreed-upon start point or “epoch.”
As it stands, the IEEE 1588 standard has a lot of built-in flexibility, allowing PTP to cover all sorts of applications, including mobile phone networking, industrial process control, automotive on-board systems, and the Internet of Things (IoT), just to name a few.
In order to accommodate all these different uses, 1588 defines a list of parameters that can be adjusted to handle a range of performance conditions. Unfortunately, all this flexibility can make it difficult to achieve interoperability between various devices.
To help resolve this conundrum, IEEE 1588 supports “profiles” which define ranges for all the allowed parameters to support a specific operating mode. Both the AES67 specification for IP audio and the SMPTE ST2059-2 specification for professional broadcast applications have well-defined PTP profiles. These two profiles are similar, but not identical. By determining an operating point where these two profiles overlap should make it possible for both audio and video signals to share the same clock and network.
That, at least, is the conclusion of a report AES-R16-2016 just published in May by the Audio Engineering Society (AES). By providing a detailed comparison of both the SMPTE ST2059-2 and the AES67 profiles, the nine authors of this document have provided a valuable service to our industry.
Based on these findings, creating an IEEE 1588 PTP clock distribution system that meets both specifications can be accomplished merely by carefully selecting values for each of the main parameters that fall within the permitted range of each standard.
For most of the major parameters in the two profiles, AES67 and SMPTE ST2059-2 have minimal differences. Both profiles support IPv4. Both specify that the default path delay measurement mechanism shall be the delay-request/response mechanism, which means that the master devices respond to requests from slave devices to achieve accurate synchronization. This is in contrast to the peer-to-peer delay measurement technique that both SMPTE and AES optionally support.
For certain parameters, one standard requires a tighter tolerance than the other; by adopting the tighter standard, a system can meet both specs. SMPTE requires a 5 ppm (parts per million) accuracy clock, whereas AES only requires 10 ppm. On the other hand, SMPTE only requires a slave to be able to adjust over a range of +/–5 ppm, whereas AES requires a range of +/– 50 ppm. Here, it appears that there could potentially be a compatibility issue, except that most (if not all) clocks used in modern networks are going to be significantly more accurate than the worst case spec, so the tighter SMPTE tolerance should not be a major issue in practice.
One interesting method that is used within IEEE 1588 to specify certain parameters is to use the base 2 logarithm of the actual value. This means that if the spec is 1, then the actual value of the parameter is 2 to the first power, or “2.” If the spec is –2, then the value of the parameter is “1/4.”
Fig. 1: Comparison of AES67 and SMPTE ST2059-2 ranges with proposed interop values For example, the time interval between successive Sync messages (sent from the master on a regular basis) are specified in AES67 as logSyncInterval is between –4 and +1, giving a range of 0.0625 (1/16th of a second) to 2 (two seconds). Fig. 1 shows a summary of the ranges for various parameters in both AES67 and SMPTE ST2059-2 as well as the proposed interoperability points described in AES-R16-2016.
PRACTICAL CONSIDERATIONS
While many of the technical issues discussed in this article might seem arcane, readers should understand that resolving the differences between PTP profiles defined in the SMPTE and AES standards is vitally important for both audio-only and audio/video networking. Already, the work done in the Video Services Forum on TR-03 (and supported by industry groups such as the Alliance for IP Media Solutions (AIMS)), has adopted AES67 as the method for IP audio transport, while also endorsing SMPTE ST2059-2. By selecting a common operating point that fits within both profiles, media streams of different types can be synchronized and a single, common PTP clock distribution system can be used.
In fact, coordinating these two standards and achieving interoperability between different devices is so important that SMPTE has formed a Task Force in conjunction with AES to perform interoperability testing during June. This will be followed by a public interoperability demonstration during the SMPTE 2016 Annual Technical Conference & Exhibition in October in Hollywood. This work is vital to the future interoperability of media networks, since clocks are fundamental to so many activities in a modern media production facility.
Wes can be contacted viawww.telecompro.tv. Thanks to Richard Bell of ARG ElectroDeisgn for his review and critique.
