Axia’s Livewire is an Audio-over-IP protocol used in broadcast environments to transport audio over IP links. All audio is completely uncompressed and encoded as 48kHz 24-bit PCM (think: WAVE files). The system has gained popularity around the world, particularly in radio facilities. Axia claims over 25,000 Livewire compatible devices have been sold.
For those unfamiliar with Livewire, the architecture is something like this:
- All audio sources are available to every Livewire device on the network via multicasting on Cisco network switches
- Analogue and AES/EBU audio is brought onto the network via “Nodes” – these are 1RU boxes with audio connectors as well as an 100Mbit ethernet port for Livewire connectivity
- Computer audio is brought onto the network via the Axia IP Driver, which looks like a traditional sound card to the operating system, but actually translates this data and puts it onto the Livewire network via a standard network card
- Every Livewire source is reference by a unique, user-definable number. These correlate to Multicast addresses.
- Dynamic event-driven routing can be done via the Pathfinder software, which can run on a Windows Server. This allows for various actions to take place based on specific triggers. This can include silence detection and studio delegation.
The result of this is a very stable, reliable, easy to use way to get audio around a facility. As it’s uncompressed, it’s not a good way to distribute audio over lower bandwidth links. For that, you would be best using some sort of MPEG codec (and interface it to Livewire with a Telos iPort).
The good news about all of this is that it’s based on open standards. That doesn’t mean the Livewire protocol itself it 100% open, although they’re working towards that with Ravenna. Protocols Livewire uses, such as RTP and Multicasting, are well supported by modern networking equipment.
Setup of Livewire on VMWare ESXi Virtual Machines
The point of this article is to document the success I’ve had with Livewire and VMWare ESXi. In one facility I work in, we have a VMWare ESXi cluster, mainly for file server tasks. However, the standards-based nature of Livewire has meant that I can run software applications such as Pathfinder and the Axia IP Driver with VMWare Virtual Machines.
There’s three configuration tricks. The first is to enable Promiscuous Mode on your Virtual Switch. This mode allows a virtual machine to listen to all traffic on a virtual switch, wether or not that traffic is intended for that VM. You can imagine how this may cause security issues in a shared environment, hence the reason it is disabled by default. The VMWare KB has an article on enabling Promiscuous Mode. If you’re running multiple hosts in a clustered environment, you would be best to enable it on all hosts.
The reason Livewire needs Promiscuous Mode is because all of the audio traffic is running around the network as Multicast packets, rather than ‘regular’ Unicast packets. Unicast packets have a specific destination, but Multicast packets are open for anyone to listen to. Promiscuous mode allows VMs to see these Multicast packets and use them as it sees fit.
The second trick is to select the ‘E1000’ network adaptor. I’ve found this is selected automatically on Windows 7 and Server 2008 VMs. If you need to add this to an existing VM, you need to remove the network adaptor and add it again. On some guest operating systems you will also need to manually install the drivers.
The third trick is not so much a trick but a piece of advice. In my experience, older guest operating systems such as Windows XP don’t work so well. You may get everything installed, and the statistics window shows packets going left right and centre, but when it comes to actually listening to the audio, well, let’s just say that nothing can actually find or listen to that stream. I’m unsure why this is, but it’s mildly frustrating. If you find a workaround to this, please share it.
At the moment, we are running Pathfinder on a VM and using it for program fail detection on several station’s feeds, as well as a few general routing events. In addition to this, we have two or three Pathfinder Mini panels sitting on computers, which have buttons and meters. We have had no issues with it since the day we migrated, over 6 months ago.
We are yet to move any playout computers to the virtual landscape, as there is no immediate need to do so. We are currently running one general purpose studio workstation on VMWare and connecting to it via a Wyse Thin Client. This machine is never used for anything critical, but some testing has indicated it is capable of glitch-free playback and recording into a DAW such as Adobe Audition.
If you have a cluster of ESXi Hosts and have High Availability and/or Fault Tolerance licensed, you can migrate VMs between hosts without experiencing downtime. In my testing of the Axia IP Driver, the only issue was a few seconds of audio ‘glitches’ as the machine migrates. We have also used vSwitch NIC teaming, and are capable of removing one of the network ports with nothing less than another few seconds of audio ‘glitches’.
If you are doing this as a planned exercise, you can arrange not to use those audio sources as it migrates. If it’s being done in an emergency, then I suppose a few seconds of slightly garbled playback is the price you pay. It’s better than loosing the whole machine, isn’t it?
One potential issue I could foresee is timing issues. This would occur if the vSwitch was not passing data through quickly enough. In the setup we have at the moment, the Host machines had plenty of spare CPU capacity and plenty of bandwidth in and out of the vSwitch. If you’re planning a larger setup it would be worth spending some time doing some capacity planning and preferably some testing to see what happens as the number of sources increases.
If you have VMWare and Axia in a facility, I encourage you to try this out. For me to get this working, it was probably a good day’s work. However, this included some time spent doing research to discover the whole “Promiscuous Mode” setting. If you can create a VM from a template and easily setup a vSwitch, then you could have Axia going within a very short period of time. Please let me know what your experience with this has been.