Setting Livewire clock when used on a wireless STL
Updated
by
Bryan Jones
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 3 with AES67) flavors of network audio packets. One is Real-time streams (we call these Live Stereo) where you need there to be no delay. Think of talking into a microphone and listening to your headphones. The "average" person can't tolerate more than about 8 to 10 milliseconds of delay, or things start to sound "out of phase" with what the bones in our ear pick up as we speak. That's why the Live Stereo streams are in .25ms packets—thousands of tiny packets at a very high rate.
Standard Stereo streams are those streams where you don't have to listen to the sound coming out of your mouth. Things like phone calls, computers that play music, satellite receivers, etc., all of these can have slightly larger packet sizes of, say, 50ms or so. Imperceptible to the human ear. Standard stereo is larger packets at a slower rate.
Consistency is key. It doesn't matter how much delay there is in any link as long as it's consistent. In other words, the timing from packet to packet can not vary by more than the packet size. Wireless connections, especially in the unlicensed space, have jitter that is too high for Live Stereo streams.
This is where Standard Stereo excels.
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.
