Operational Levels

TOPIC is designed in such a way that in the event of a failure within the network, there is some form of failover in place that allows the controlled transmission of audio between devices to continue, with the loss of as little functionality as possible.

With this in mind, TOPIC can operate in four distinct ways, called Operational Levels, depending on the capabilities of the devices within the Network.

The lowest level of the Network assumes that only audio devices exist within the Network, and each device operates on a multicast basis. As the capabilities of the Network increase, further complexity in terms of control and audio routing becomes available. However, if these devices fail, the audio devices will still be able to transmit and receive audio on a functional - though somewhat inflexible - level.

1. Multicast

This is the lowest Operational Level. A TOPIC Network will drop into this OL when the only functioning devices on the Network are uncontrolled audio devices (such as audio interfaces, for example). There is no control available here, all devices capable of transmitting to all other devices without restriction. Since these devices are not controllable per se, connecting a configuration client to the network will not allow the user to create audio patches across the Network.

2. Peer-To-Peer

This OL is utilised when the only functioning devices on a TOPIC Network are controllable audio devices (such as IP key-panels). These devices are capable of holding and obeying patching information, which allows some level of routing control across the Network. When a configuration client accesses the Network, either:

• Each audio device holds the entire patch in memory, or:
• Each audio device only holds the patches that are relevant to it (as in, which devices that it can send to and listen from) and the config client traverses the Network and builds the overall patch based on which devices are routed to each other.

When the user alters the patch, the new patching information is propagated across the network (somehow) and each device updates its own patches. This is the lowest OL with routing capabilities (whereas devices on a OL1 Network receive audio from all other devices on the network).

3. Arbitrated Peer-To-Peer

If an Arbitration Server is connected to the TOPIC Network, this takes over maintainance and propagation of audio patches across the Network. This means that if a config client is connected to the Network, it interfaces with the Arbitration Server directly, which holds the patch centrally, rather than having to traverse the Network and build the patch. It also means that audio devices do not have to propagate changes in the patch across the Network themselves; instead they receive patch information from the Arbitration Server.

This is the lowest OL with a centralised routing control, whereas the lower OLs required devices to hold their own patching information. However, since the Arbitration Server sends the new patches to audio devices when the patch changes, the audio devices will always hold the latest routing information and can use this if the Arbitration Server fails and the TOPIC Network drops into OL2.

4. Arbitrated-Matrixed

This is the highest and most complex OL. If a Matrix is connected to the TOPIC Network, then it takes on the role of managing all mixing, processing and routing of audio streams across the Network. When a config client connects, it interfaces with the Matrix. When the patch is changed by the user, it also updates each audio devices' patching information, thereby making the Arbitration Server redundant.

Therefore, a TOPIC Network with a Matrix will work perfectly well without an Arbitration Server, since the Matrix takes over its duties. Since a TOPIC Network with a Matrix can be presumed not to have an Arbitration Server, it is possible for the Network to fail straight from OL4 to OL2.