The author is senior development engineer at Wheatstone.
AES67 has emerged as an important standard that will eventually find its way into every broadcast plan that includes audio. With AES67 being the audio transport standard defined by SMPTE 2110-30 and supported by major IP audio network systems, all that remains is for broadcasters to commission AES67 in their plants.
There are several key AES67 commissioning practices I’ve observed in the field and with a large, simulated studio network that included over a hundred AES67 compatible consoles, software applications, automation systems and controllers.
MAPPING IT OUT
The first step in commissioning AES67 is to map out an IP and stream multicast address plan that assures every stream on every device will have a unique address available, keeping in mind that multicast traffic is not normally routed across subnets.
This is critical because the different devices in various AoIP networks can’t “see” each other, and therefore it is entirely possible that they may be using address settings already in use elsewhere.
To make a stream multicast address plan, note all the different devices that will be in the system and how they allocate multicast stream addresses. Start with the devices that are least common or least flexible in specifying or changing multicast addresses and isolate them in an address range, well removed from what the majority of your devices will be.
[Solving the Missing Link]
Multicast addresses are in the form of 239.xxx.yyy.zzz. Each AoIP vendor has their own way of allocating addresses for each stream. WheatNet-IP does it automatically (although you can change the starting address and range, if needed), whereas Dante will let the user specify the xxx octet of the address but automatically generates the yyy and zzz.
Therefore, when adding two Dante devices to a WheatNet-IP system with 50 Blades, the Dante device streams would be given a multicast address of .192 for the second octet to produce a multicast address Dante autoassigns. Then, the WheatNet-IP devices can auto-generate multicast addresses starting lower (239.192.192.1) or higher (239.192.yyy.zzz+10), ensuring that there are no WheatNet-IP streams assigned the same multicast addresses.
It’s important to go through the effort of creating a plan first, because as you add AES67 devices to the system, you will be doing a lot of hand entry and specifying stream addresses the devices are using to transmit on and which stream address devices are using to receive.
If you go through all this effort only to discover that some other device is using that same address, you will only have to start over. Having a multicast address plan in place will be useful later when routing AES67 streams in your network; it’ll be referred to over and over again.
PACKETS AND TIMING
It’s also important that both systems are synchronized and use the same packet structure, which varies depending on devices and systems used in the network.
AES67 specifies the PTPv2 protocol to synchronize all the devices in the network, which 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.
While this degree of timing accuracy is normally not required for a typical AoIP installation, we find that an ordinary crystal oscillator in a PC or I/O device is nowhere near this accurate and stable enough when used with a multiplicity of various devices. In most cases, a standalone PTPv2 master clock device works best to serve the role of timing generator to which all other devices slave their timing.
For packet structure, we suggest setting devices and system sample rates to 48 kHz as AES67 favors the 1 msec packet timing seen in all of the specifications, which equates to 48 samples left-right interleaved in a stereo stream.
Dominic Giambo has been involved in industry AES67 plugfests as the lead engineer responsible for AES67 implementation in the WheatNet-IP audio network.
Radio World welcomes proposals about best practices in AoIP as well as other technical topics. Email [email protected].
