Designing Livewire Channel Numbering Schemes

While utilizing an IP network for an audio patch field isn't a unique idea these days, the notion of designing a scheme for the Livewire channels can be. There are a few strategies we have practiced over the years that curtail the possibility of creating duplicates of forgetting what channel belongs to which device.

There is no right or wrong way to do it. It's only important to do it in such a way that many years down the road, the user is able to remember what goes where and how to not accidentally assign a LW channel number that already exists on the network to a new device.

Duplicate Livewire channels cause audio distortion and in many cases, logic problems that can bewilder the user or installer. Confusion ensues and time is wasted, so it's important to design a strategy early on and stick to it.

The "Last Octet" method:

This is a strategy where the last byte of the device's IP address is used as the first few digits of the Livewire channel number. For example, we'll commission an xNode using IP address 192.168.2.108. We'll number the inputs (sources) as 10801, 10802, 10203 and 10804.

When the system is set up in this way, we can immediately tell what IP address the device is that is creating source channel number 10802. Inversely, if we know that the IP of this xNode is 192.168.2.108, we can immediately say that the channel range for this device starts at 10801 without looking at the UI. Pretty cool.

Deep Tech Note: The 4 bytes of an IP address are called octets because they each contain 8 bits, whose combination of 1's and 0's determine the value expressed between the dots. This also explains why the range of an IP address byte is 0-255. With 8 bits, there are only 256 combinations of 1's and 0's available. This is also why you may see subnet masks represented by an integer instead of an address. For example, an 8-bit subnet mask is 255.0.0.0 while a 16-bit subnet mask is 255.255.0.0.

There are situations where this doesn't work so well. These situations include (but are not limited to) setting up a device that has more than 10 sources (like Powerstation), and using Axia on a 10.0.0.0 network with a low subnet mask.

In the case of the Powerstaton, there are devices on board that have IP addresses but don't broadcast audio to the network. For example, the Powerstaiton's internal switchboard and the ETH4CAN Fusion interface board.

Inversely, there may be a device (or many devices) on the network that only broadcast 1 or 2 streams. So this can lead to huge holes in the scheme.

Node ID method:

This method is not as old but can be just as effective. Since there are only 254 IP addresses available on a class C network like the one in our example, and since there are 32767 channel numbers to choose from, we can see that there are more channels available than the ones we can use in the "Last Octet" scheme above. Essentially, channels 25401 (or so) through 32767 will be completely unused.

The xNode already needs the user to configure a node ID in the SIMPLE SETUP page, so it give the user the option to use the node ID as the first few digits of the channel number:

Each xNode will display it's node ID on the front panel, so we'll know what channels are assigned to the sources based on this information. It also gives us the opportunity to set aside ranges that will be used for devices that use a lot of source channels. (ie: Z/iPort, Powerstation, VX, IP drivers, etc.)

Any other method is fine

There are only two rules for designing a Livewire channeling scheme:

  • 1) The channel number can't be lower than 1 or higher than 32767
  • 2) No two devices are allowed to use the same Livewire source channel number (no duplicates)

That's it, there are no other rules. The methods described are just a roadmap. A combination of the above methods can be used as well as completely different methods that aren't mentioned here.

In this case, the only other rule we could add is to pick a scheme and don't deviate.

How did we do?