Wheatstone Corporation WheatNet-IP BLADE3, Техническое руководство

Страница: 343 / 366

WheatNet-IP BLADE 3 / June 2018
page A – 114
A P P E N D I C E S
The theory is that if a device uses the prescribed protocol in the packet header to
identify them and fills the packet payload in the prescribed manner, other devices will
be able to receive the packet and reassemble the payload into the correct audio signal.
In fact this works and the rest of this chapter is about how to use WNIP Navigator to
send and receive streams with other devices configured to the AES67 standard.
System Requirements
Timing
One of the key problems AES was faced with when creating the standard was how to
keep disparate audio devices all synchronized so audio would playback without clicks and
pops due to sample rate and timing mismatches. Here’s the problem – in WNIP Blades
all synchronized their internal clocking to a special signal that the system distributes to
every Blade. We call that signal the “metronome” and we send it around the network
many times per second to keep all of the individual clocks in Blades that actually play
out audio in sync with each other. We developed this method of synchronization back in
2004 when we started making WNIP. Axia did something on their own with Livewire
for the same purpose, and other vendors did yet something else. We each did our own
thing because back in the day there was nothing suitable for the purpose; we had to invent
something to make it work.
Natively WNIP can’t synchronize an xNode and vice versa. Same with the others
because we all use our own inventions for the purpose. AES67, in recognition of this
difficulty, specifies a method to share synchronization amongst devices, a standard tim ‑
ing protocol that has come out in recent years; IEEE-1588, also known as the P recision
T ime P rotocol, or PTP. In fact the standard specifies a particular version of this protocol
known as PTPv2.
So for an AoIP system to maintain timing and stay synchronized with other AES67
devices, the system timing must be controlled by PTPv2. For that to occur there must be
some device in the system that serves the role as PTPv2 timing generator to which all other
devices slave their timing. Generally that role is filled by a specialized PTP master clock
device because the PTPv2 protocol is so precise that in the best circumstances (PTPv2
master clock synced to GPS for absolute timing reference and PTP aware switches used
for reference signal distribution) timing accuracy of better than 1 microsecond can be
achieved. An ordinary crystal oscillator in a PC or I/O device is nowhere near accurate
and stable enough for this performance level, hence the need for stand alone Master Clock
generators.
Sub‑microsecond timing accuracy is not required to maintain click free audio however,
so if your main concern is clean audio and you’re not worried about absolute timing
accuracy you can dispense with the added expense of PTP aware switches and use a basic
PTPv2 master clock. Some AoIP devices will actually provide a PTP reference clock
signal themselves, however their timing accuracy is typically poor.
Bottom line – To use AES67 devices your system must have a PTPv2 clock reference
device.