Scope
This document covers proper settings when using Livewire nodes over "high jitter" links. This is most often found when using unlicensed wireless links for STL.
Description
No matter what your Livewire network looks like, a stable clock is a requirement. Not clock, as in "time-of-day" but clock as in something to tell all of the other devices what RATE the packets will be arriving. On a traditional wired network, this happens automatically and without thought. When Greg Shay and Maciej Szlapka invented Livewire, they spent the most time making sure a stable clock could be achieved. One of the patents covers synchronization explicitly.
Fast forward many years, and now people want to use Livewire on wireless links where there is high jitter. Fortunately, some foresight makes this possible.
Achieving success on high-jitter links
There are two (now three, with AES67) flavors of network audio packets. One is Real-time streams (we call these Live Stereo), where you need there to be virtually no delay. Think of talking into a microphone and listening on headphones. Most people begin to notice delays somewhere around 8–10 milliseconds, so minimizing latency is important. Live Stereo streams use very small 0.25 ms packets sent at a very high rate.
Standard Stereo streams are intended for sources where a few milliseconds of additional delay is not important. Things like phone systems, automation computers, satellite receivers, streaming decoders, and similar sources work well with Standard Stereo. These streams use 5 ms packets, reducing network overhead while still maintaining low latency.
To put that into perspective, a Live Stereo stream sends approximately 4,000 packets per second, while a Standard Stereo stream sends about 200 packets per second. The larger packets and lower packet rate make Standard Stereo streams less sensitive to network jitter and packet processing overhead.
AES67 streams typically use 1 ms packets and are primarily intended for interoperability with third-party AES67-compliant equipment and have a packet rate of 1000 packets per second.
Consistency is key. The absolute amount of delay is often less important than the variation in delay (jitter). As long as packets arrive consistently, audio will play reliably. Wireless connections, particularly those operating in unlicensed spectrum, often introduce enough jitter to cause problems with Live Stereo streams.
This is where Standard Stereo excels. Because each packet contains more audio data, occasional variations in packet arrival time are less likely to affect playback. For links where network conditions may not be ideal, Standard Stereo streams often provide more reliable performance than Live Stereo streams while still maintaining audio quality and very low latency.
Configuring the nodes at the "remote" end
From your web browser, log in to each node at the far end of your wireless link.
Under the Advanced options heading, click on Synchronization and QoS.
From the Clock Mode: configuration select Livewire STL Snake Slave (high-jitter links, standard streams only) from the dropdown list as shown here.
Apply your settings.
Applying this setting will force the node to subscribe only to the "slow" clock used for Standard Streams.
Configuring the nodes at the "studio" end
Since we only subscribe to the Standard Stream clock, we can only send Standard Streams to the remote end.
Here is an example from an xNode.
From the web page, click on the Sources link.
Set the Stream Mode: for any streaming being delivered to the remote end to Standard Stereo, as shown here.
Apply your settings.
Considerations for other sources
Sometimes you may need to "convert" a source from a Live to a Standard stream. For example, if you're listening to Program 1 directly, you won't be able to convert it to Standard directly. However, audio often goes somewhere else before going to the transmitter site. For example, a profanity delay, Emergency alert encoders, watermark encoders, etc. You can also use a Vmix in any console engine to create an additional Program 1 stream but at the Standard stream rate.
Let us know how we can help
If you have further questions on this topic or have ideas about how we can improve this document, please contact us.