The Need For Sync - In any audio environment where multiple pieces of equipment are being used together, it is imperative that they are synchronized. If they do not run in time with each other it will be difficult - if not impossible - to produce a coherent end result where everything fits where it is supposed to.
In the early days of digital audio, the problem of getting the new generation of tape machines to run in sync with each other, as well as associated equipment such as compact disc players, was solved through the development of word clock. This is based on the concept of clocking every audio sample. The samples are contained in data words (a word being a vector of bits that are dealt with as a unit), which are long enough to contain an instruction, in this case about time.
Synchronization for analog color video transmission (PAL, NTSC and SECAM) was achieved using black and burst (alternatively called black burst and bi-level sync). This is a reference video signal that can be transported over regular video cables and distribution modules.
The purpose of word clock was to maintain an exactly timed and constant bit rate that would prevent mistakes in timing, which could result in data transmission errors. Word clock proved extremely efficient for synchronizing equipment in self-contained environments such as a recording studio. Today, however, facilities rarely operate in complete isolation.
TSL now offers IP connectivity across its entire audio range.
Widescale networking, enabled by audio over IP (AoIP), is now the norm and distributed word clock was not seen as the synchronization tool for the job. This was because a large amount of data and bandwidth would be needed to send clock signals around an IP network. Working over distance and maintaining noiseless, uninterrupted data streams were also a problem. A solution, which would replace word clock as the main source of sync for audio, was found, as in increasingly the case for professional audio and broadcasting these days, in the world of IT.
Precise Time Keeping With PTP
The precision time protocol (PTP) was developed by the IEEE (Institute of Electrical and Electronics Engineers), with the first version appearing (as IEEE 1588) in 2002. It was designed to provide more accurate timing over a local computer network than the existing NTP (network time protocol) technology and be used in situations where GPS (global positioning system) could not be used for technical or cost reasons. PTP is based on the principle of a main device as the clock source with many other devices connected and running to it. This is known as a leader/follower configuration.
PTP works to the same epoch as Linux and Unix computing systems, with a start date of 1 January 1970. This produces a reference in the form of a time and date that can be applied to an audio packet when it is created. This could be useful in terms of moving audio across a network, particularly as IP is non-deterministic (that is, how long a packet will take to be delivered is not known for certain). If a packet takes longer than expected to get across the network, having the time it was created is an advantage compared to older sync methods. For big PTP networks, a GPS reference can be used to maintain absolute clock accuracy between physically separate locations.
In the mid to late 2000s, AoIP began to expand beyond existing proprietary systems such as Livewire, with the aim of creating larger audio networks. Dante appeared in 2006, initially aimed at live sound applications but it has since made a considerable impact in broadcast. Devices supporting this protocol, which was developed by Audinate, are capable of being both leaders and followers, which means an external clock is not necessarily required. Another advantage is that accurate PTPv1 timing can be provided by low cost, off-the-shelf switches.
Advantages Of PTP For Broadcasting And AoIP
Historically, word clock for a broadcast network would have had separate video synchronization, with its own cabling to media connections. SDI routers had a cable for every video input and output, with another for the sync signal. With IP it is possible to provide sync across the network and media traffic using only one cable per device. This is also able to bring in metadata and control information.
Audinate chose PTP (v1) as the clock for Dante because it was the network standard at the time, which enabled audio to be delivered over IP networks with both phase and microsecond accuracy. An updated version of PTP appeared in 2008 and was selected for the RAVENNA AoIP system when it came on the market in 2010. PTPv2 provided additional features and enabled even greater timing accuracy, including transparent and boundary clock options.
A transparent clock can measure packet delay and adjust for it. Transparent clocks are also able to compute the variable delay as PTP packets travel through the switch or router. A boundary clock puts a local PTP clock into operation. This can be synchronized to a leader on one port and run as a leader on other ports.
PTP works by having a leader clock and, potentially, 1000s of end points talking to it. By adding a component such as a transparent clock in the middle of this, data can be divided into smaller chunks and sent to sub-groups, thereby reducing the amount of traffic. A boundary clock is like an edge point; it knows there is a leader clock but prevents end point devices from talking directly to it. This reduces the amount of traffic on a network and can be more manageable for large installations by using unicast messaging rather than multicast (as used in PTPv1).
Expansion Of AoIP And Increased Adoption Of PTP
Dante and RAVENNA are both AoIP solutions, but they were not compatible when first launched. This was addressed by the Audio Engineering Society, which in 2013 announced AES67 as an interoperability standard that could be used to connect discrete networks based on different AoIP systems (Dante, RAVENNA, Livewire). In terms of sync capability, AES67 utilizes PTPv2. When Audinate released a firmware update to support AES67 operation on Dante devices this included the ability for a Dante device to use PTPv2 for synchronization. This is an important feature because it means it is possible for a Dante device to simultaneously support both PTPv2 (for AES67 operation) and PTPv1 (for non-AES67 enabled Dante devices) in a mixed network, with the AES67-enabled Dante devices acting as a boundary clock between the two standards.
Further standardization of IP in broadcasting came in the form of SMPTE ST 2110, which also relies on PTPv2 for synchronization. This is detailed in ST2110-10 (covering system architecture and synchronization), which provides flexibility in the implementation of PTP. It is important that all end devices and the PTP GM (grandmaster) are configured with the same parameters, including the PTP domain number. Dante natively manages these settings for the devices, which reduces the complexity of the set-up, however additional configuration tools are available for full ST 2110 compatible installations.
Synchronization and timing are background technologies that might appear somewhat inaccessible and overly technical. That is an understandable reaction but, as with any technology, whether you use PTPv1 or PTPv2 depends on what you are doing. There is nothing wrong with version 1 and it is perfectly adequate for both small, simple networks and larger audio-only installations. But for bigger broadcast networks with a large amount of equipment, a more dedicated and PTP aware infrastructure based on version 2 is required.
Manufacturers and systems integrators can advise on the best route to take and recommend what synchronization is necessary. The main thing to remember is that this side of an installation does not need to be scary, even if it is a subject that takes time to understand.