Product Information…Studer RELINK 6 SW V2.0 Date printed: 13.03.09 2.1.7 NETInput (not available for Vista consoles) A NETInput is a virtual object in a two-step I/O sharing setup

Product Information(March 2009, 3rd Edition)

Prepared and edited by Copyright by Studer Professional Audio GmbHStuder Professional Audio GmbH Printed in SwitzerlandTechnical Documentation Order no. BD10.275210-2 (0309)Althardstrasse 30CH-8105 Regensdorf – Switzerlandhttp://www.studer.ch Subject to change

Studer is a registered trade mark of Studer Professional Audio GmbH, Regensdorf

Studer RELINK

Date printed: 13.03.09 1SW V2.0

CONTENTS

1 Strategic Concept ................................................................................................................................................................ 3

2 Functional Concept ............................................................................................................................................................ 4

2.1 I/O Sharing Defi nitions .................................................................................................................................................. 42.1.1 Single-Step I/O Sharing ........................................................................................................................................ 42.1.2 Two-Step I/O Sharing ........................................................................................................................................... 52.1.3 Ethernet - TCP/IP Network ................................................................................................................................... 52.1.4 System ................................................................................................................................................................... 52.1.5 NETSource ............................................................................................................................................................ 52.1.6 NETConsumer ...................................................................................................................................................... 52.1.7 NETInput (not available for Vista consoles) ......................................................................................................... 62.1.8 Net Mode / Static / Dynamic Connections ........................................................................................................... 62.1.9 Physical Connections ............................................................................................................................................ 62.1.10 Logical Connections ............................................................................................................................................. 62.1.11 Active .................................................................................................................................................................... 6

2.2 Signaling and Remote Parameter Control ...................................................................................................................... 7

2.3 Signal Routing ................................................................................................................................................................ 8

3 Topologies ............................................................................................................................................................................ 9

3.1 Peer-to-Peer Setup .......................................................................................................................................................... 9

3.2 Triangle Setup ................................................................................................................................................................ 9

3.3 Star Setup ....................................................................................................................................................................... 9

3.4 Functionality ................................................................................................................................................................ 11

4 Application Examples ....................................................................................................................................................... 12

4.1 Example 1: Shared News Booth .................................................................................................................................. 12

4.2 Example 2: Shared News Booths, Central Router ....................................................................................................... 13

4.3 Example 3: Radio Broadcast and Production House ................................................................................................... 14

5 Operation ........................................................................................................................................................................... 15

5.1 Signals to be Shared: Overview ................................................................................................................................... 15

5.2 OnAir ........................................................................................................................................................................... 155.2.1 Using Shared Signals .......................................................................................................................................... 155.2.2 Mic Take-Over Procedure ................................................................................................................................... 15

5.3 Vista ............................................................................................................................................................................. 165.3.1 Input Patching ..................................................................................................................................................... 165.3.2 Output Patching .................................................................................................................................................. 175.3.3 Mic Take-Over Procedure ................................................................................................................................... 185.3.4 Vista Restrictions ................................................................................................................................................ 21

6 Technical Details on the OnAir Side ............................................................................................................................... 22

6.1 OnAir Setup for I/O Sharing ........................................................................................................................................ 226.1.1 Defi ne a Physical Connection ............................................................................................................................. 226.1.2 Defi ne Logical and Patch Inputs, Ext. PFLs, Ext. Monitoring Sources .............................................................. 246.1.3 Defi ne Net Inputs ................................................................................................................................................ 26

Studer RELINK

Date printed: 13.03.092 SW V2.0

7 Technical Details on the Vista side .................................................................................................................................. 28

7.1 Setting up the Vista for I/O Sharing ............................................................................................................................. 287.1.1 Confi gTool for DNet Applications ...................................................................................................................... 287.1.2 Restricting Shared I/O ......................................................................................................................................... 327.1.3 Confi guration Changes ........................................................................................................................................ 327.1.4 Container.ini ........................................................................................................................................................ 337.1.5 D950System.ini ................................................................................................................................................... 34

7.2 Tie Line Management .................................................................................................................................................. 35

7.3 Control Network ........................................................................................................................................................... 357.3.1 Vista 5 ................................................................................................................................................................. 357.3.2 Vista 6, 7, 8 ......................................................................................................................................................... 367.3.3 IP Addresses ........................................................................................................................................................ 36

7.4 Audio Sync for all Systems ......................................................................................................................................... 37

8 Glossary ............................................................................................................................................................................. 38

9 Recommended Network Setup Examples ...................................................................................................................... 39

9.1 Vista 8 and Vista 5 – with a Switch .............................................................................................................................. 39

9.2 Vista 8 and Vista 5 – Peer-to-Peer ................................................................................................................................ 40



9.5 Vista 8, Vista 5, Route 6000, OnAir 3000 .................................................................................................................... 43

Disclaimer The information in this document has been carefully checked and is believed

to be accurate at the time of publication. However, no responsibility is taken by us for inaccuracies, errors, or omissions, nor is any liability assumed for any loss or damage resulting either directly or indirectly from use of the information contained within it.

Studer RELINK


1 Strategic Concept Note: Studer RELINK incorporates existing technologies such as Studer’s I/O Shar-

ing (OnAir series), and the implementation of I/O Sharing into Route 6000 and Vista, plus future enhancements to these technologies.

In our everyday project business, we increasingly face trends that are driven by individual customer desires, financial restrictions or environmental limita-tions. One of these challenging trends is to extend the idea of an audio system from being an enclosed mixing device with I/O core and control surface to a distributed network of audio nodes without any limiting boundaries. This does not mean any change to the definition of a mixing console as such, but affects the understanding that resources, such as input and output signals, have to be connected directly to the device using them.

Customers are intensively looking for cost-effective project solutions in economically challenging times. At the same time, they do not look for a pure technical solution anymore, but rather for a well integrated application. Indeed, a seamless and user-friendly integration of distributed resource avail-ability will have a significant advantage for the customer, since the setup and maintenance efforts are clearly laid out, and the learning curve for operators is short.

I/O Sharing offers measurable benefits: • I/O Sharing enables every input or output within an audio network to be

available anywhere in the network, requiring a minimum number of audio interconnections.

• I/O Sharing allows installing codecs centrally and managing them between different studios in an intelligent way, instead of investing in exclusive codecs for each single studio.

• I/O Sharing allows for comfortable switching between different rooms, e.g. two on-air studios.

Studer RELINK


2 Functional Concept In a networked installation with multiple Studer digital mixing consoles and

routers connected to each other, I/O Sharing (Input/Output sharing) enables every single device to consume shared signals from any other device within the network.

Consuming and sharing audio signals requires a standard infrastructure for audio and control signals. It may already exist, or it must be possible to be set up using additional standard I/O modules and wiring. In order to enable I/O Sharing, the system software of a Studer device may require an upgrade to a new version. In some cases an additional software license may need to be installed.

I/O Sharing of audio signals is based on two elementary technical require-ments:

1 A TCP/IP network between all Studer consoles which consume and share resources.

2 A suitable amount of physical connections (tie lines) between the devices involved that will exclusively be available for I/O Sharing. The amount of physical connections between two devices defines the number of signals which can be shared simultaneously.

Note: Having just a TCP/IP network or physical connections for audio signals avail-able is not sufficient for I/O Sharing. Both requirements must be fulfilled.

2.1 I/O Sharing Definitions2.1.1 Single-Step I/O Sharing

Single-step I/O Sharing is an application of two devices (systems) con-

nected directly. Each of them may share signals with the other. The figure above shows two systems, with ‘System A’ being locally connected to three microphones, and ‘System B’ consuming those microphones via a physical connection. Both systems are networked via Ethernet.

Studer RELINK


2.1.2 Two-Step I/O Sharing

Two-step I/O Sharing is an advanced signal sharing application. It allows sharing of signals between two devices ‘through’ a third device. In the figure above, ‘System A’ and ‘System B’ are not connected directly but through the central router device ‘System C’. System A provides a set of three micro-phones to the router. These microphones are available as NETInputs in the router and can be consumed by System B in the same way as local sources.

2.1.3 Ethernet - TCP/IP Network

All devices sharing signals and parameter access have to be configured and connected to the same network. IP addresses must be configured in the same subnet. For TCP/IP setup, please note that some I/O sharing systems might be depending on pre-defined IP addresses.

2.1.4 System

A System consists of one core at least. This may either be a mixing console (like Vista 5, Vista 8, OnAir 2500, OnAir 3000), or a router (Route 6000).

2.1.5 NETSource

A NETSource is a shared signal from a system that can be consumed by other systems within the same audio network. NETSources can have dif-ferent signal types and are not limited to e.g. physical inputs. For example, NETSources can be logical inputs, patch inputs (‘consumers’) and master outputs (‘producers’). The system configuration defines which system signal is available as a NETSource.

2.1.6 NETConsumer

Incoming Signals that are dedicated to a particular standalone console are defined as ‘Consumers’. E.g. if the console is networked and the incoming signals are NETSources physically connected to another system, they are defined as ‘NETConsumers’.

NETConsumers can have their own channel format that needs not being identical with the one of the NETSource.

Studer RELINK


2.1.7 NETInput (not available for Vista consoles)

A NETInput is a virtual object in a two-step I/O sharing setup. It is used on the system in the middle position and it is configured in the same way a NETConsumer is. It is virtual, and its only function is to be consumed by a NETConsumer on the third system. NETInputs have to be configured on static logical connections.

Note: Only Routers and OnAir consoles can have what we call ‘NETInputs’. This implies that either a Router or an OnAir console needs to be in the center of a ‘two-step’ system (chapter 2.1.2). A Vista console must be at one of its ends.

2.1.8 Net Mode / Static / Dynamic Connections

Net Mode is a consumer attribute, defining the NETConsumer to be static or dynamic, respectively. If a NETConsumer is specified to be static, the Logical Connection is connected permanently and the physical connection(s) is /are exclusively reserved for it. If it is specified to be dynamic, the logical and the physical connections are connected only if the NETConsumer is active (processed). As soon as the NETConsumer is not active anymore, its connec-tions will be released and become available to other NETConsumers.

2.1.9 Physical Connections

A physical connection is a tie line between two systems, reserved for sharing signals. It can be either be the full amount of lines on a cable connection (2 lines on an AES connection) or a selection of available lines (e.g. 30 of 64 MADI channels). The media for physical connections can be of any type: analog (Line), AES, ADAT, MADI, or even HD Link, etc. The amount of physical connections between two devices defines the maximum number of signals that can be shared between them. A physical connection is exclusively reserved for I/O Sharing and cannot be used for any other application, like fixed signal patching between two devices.

2.1.10 Logical Connections

When a NETSource is assigned to a NETConsumer (a consuming system), a logical connection for this particular source is established. A logical connec-tion just defines the source by its name but has no specification of the signal’s format.

In OnAir consoles and Route 6000, HD links are treated as Mono connections while configuring the physical input mapping.

2.1.11 Active

A NETConsumer is called active when it is actually consuming audio from the allocated NETSource (i.e., either on a strip channel, or assigned to an output, or routed to the monitoring, or selected as a meter source, etc.). This is the final condition that has to be met for the signal state of a NETConsumer to be OK.

Studer RELINK


2.2 Signaling and Remote Parameter Control I/O Sharing allows a two-level use of shared input signals. Pure consump-

tion of a shared audio signal is always possible as long as a NETConsumer is configured to consume a particular NETSource from another system, and sufficient free physical connections are available between the two systems. The real challenge in a shared-signal environment is posed by making signal parameters that are physically bound to a resource and cannot be regenerated at any other place available to remote, consuming consoles, such as micro-phone phantom power or analog gain. To control these, pure consumption of the shared signal is not sufficient. The remote, consuming console must also have access to these parameters, it must become the ‘owner’ of these parameters. This is an exclusive state.

If the consumption of a signal is linked to logical resources, like a microphone activating a red light if opened and/or cutting a speaker in the same room, I/O sharing takes care of controlling these remotely as well. These logical resources will be triggered by the remote, consuming console that needs not being the ‘owner’ of signal parameters in order to trigger the resources.

On the OnAir consoles, signaling is coupled with the I/O Sharing, meaning that redlight or fader start signaling connections are automatically follow-ing to any console using the audio signal and applied correctly to the source (studio, CD player, etc) from anywhere.

Studer RELINK


2.3 Signal Routing A NETSource can consume the signal(s) of a NETConsumer, independent

of their individual formats. In order to consume audio, a NETSource must be allocated to a NETConsumer. There are two different ways of allocation: automatic (logic) or mono.

Each NETConsumer (specified in chapter 2.2) provides up to six sources. The first source can either be a logical NETSource or a distinct mono signal

of a NETSource (Left, Right, Center, LFE, Left Surround, Right Surround, Downmix Left, Downmix Right or Downmix Mono). The second to sixth sources can only be distinct mono signals of a NETSource.

If the first source is a logical NETSource, all consecutive sources are ignored and greyed out in the Configuration Tool.

If a NETSource is automatically allocated to a NETConsumer, up to six sig-nals of the first source will be linked when the NETConsumer gets active, as indicated in the table below.

NETSource Format

NET-Consumer

FormatLeft Right Center LFE Left Surround Right Surround

5.1 /5.1 with DwnMix

5.1

Left Right Center LFE LeftSur RightSur

st /st with DwnMix Left Right - - - -

m Left Left - - - -5.1 with DwnMix

Stereo

DwnMixLeft DwnMixRight - - - -5.1st

st with DwnMixLeft Right - - - -

m Left Left - - - -5.1

Mono

Center - - - - -5.1 with DwnMixst with DwnMix DwnMixMono - - - - -

stm Left - - - - -

If a NETSource is allocated to a NETConsumer based on individual mono signals, the signals of the NETConsumer are defined by the corresponding source parameter:

NETConsumer Format Left Right Center LFE Left Surround Right Surround

5.1 Source (left) Source Right Source Center Source LFE Source Left Sur Source Right SurStereo Source (left) Source Right - - - -Mono Source (left) - - - - -

Audio Parameter Copying When a NETConsumer is allocated to a NETSource, all audio parameter set-tings – such as EQ, dynamics, panning etc. – are copied from the NETSource to the NETConsumer. Once this allocation is finished, all parameters will be saved individually.

Studer RELINK


3 Topologies

3.1 Peer-to-Peer Setup The simplest topology for using I/O Sharing is a two-console setup, where

one of the consoles is physically connected to a resource that might be used by the second console from time to time.

In a simplified block diagram this would look like this:

3.2 Triangle Setup In this topology, three consoles are connected together. Direct physical con-

nections must be provided between from each console to every other console. Each console is able to offer some of its I/O to the other consoles for sharing. Therefore each console serves at the same time as provider as well as con-sumer. This makes this solution very cost effective, since the only additional cost is some added I/O for interconnection of the consoles.

3.3 Star Setup For installations with more than three systems involved, the central star router

allows maximum flexibility while requiring a minimum of physical connec-tions. Connected shared sources need to be configured as ‘NETInputs’ on the star router: NETInputs are used to make a neighbouring NETSource statically available to all NETConsumers in order to be available for other consoles.

Studer RELINK


A star topology bears the risk of a single point of failure – when the router fails, no shared signals are available at all. For failsafe operation the router has to be equipped with redundancy.

Typical star topology example: OnAir and Vista consoles directly connected to the router:

Star topology example: Consoles and some additional I/O connected directly to the router:

The advantage of connecting I/O frames to the router directly is that the con-soles do not need to be powered all the time if some shared I/O ‘from other consoles’ is needed.

Studer RELINK


Star topology example: Additional redundant audio link from an I/O frame directly to a console:

If the router fails, the lower Vista console can still access the I/O from the remote frame.

Please note that a two-step connection is the maximum, as shown in chapter 2.1.2 and the first example on the previous page (OnAir – Router – Vista).

Note: Only Routers and OnAir consoles can have what we call ‘NETInputs’ – Vista consoles cannot. NETInputs are required for passing on shared sources to other ‘consumers’. This implies that either a Router or an OnAir console needs to be in the center of a ‘two-step’ system. A Vista console must be at one of its ends.

3.4 Functionality In all of the topologies above, direct access to sources and targets throughout

the entire network is given – provided that the desired sources and targets are configured as NETSources and therefore available for remote components of the system.

Mic control take-over mechanisms are implemented on both the OnAir and the Vista consoles.

On the OnAir consoles, signaling is coupled with the I/O Sharing, meaning that red light or fader start signaling connections are automatically following any console using the audio signal and applied correctly to the source (studio, CD player, etc) from anywhere.

Studer RELINK


4 Application Examples

4.1 Example 1: Shared News Booth A very common application in radio houses is a voice or news booth connected

closely to a studio for speech contribution to a broadcast or a recording, while a second studio is used for production. The booth resources (microphone, headphones and indication) are physically connected to one console, usually to the one used most in combination with the booth (the one in Studio 1 in our example). This console provides the monitoring signal for the headphones, controls the microphone parameters as well as the ready/on air indicators.

If the second studio (Studio 2) requires the booth for production, I/O Sharing allows forwarding the control of the microphone parameters and the indica-tion from the console in Studio 1 to the one in Studio 2. Via a physical con-nection (tie line) between both studios, the audio signal is provided to Studio 2. This audio interconnection can be of any type, for example AES3.

The monitoring signal for the headphones is still provided by the console in

Studio 1, but the monitoring signal is delivered by the console in Studio 2 via a suitable tie line (e.g. AES3) and routed to the headphones remotely.

While Studio 2 works with the booth, it controls the microphone parameters, including analog gain and phantom power. Opening the microphone in Studio 2 activates the red light in the booth, presuming that the ‘mic on’ parameters are configured accordingly. In this case, existing monitor speakers will be cut remotely as well. Sharing the control information is established via a network connection (Ethernet) between all systems involved.

Studer RELINK


4.2 Example 2: Shared News Booths, Central Router In this larger installation, a number of studios in the same facility are used to

feed and produce signals, for example for two independent programs.

OnAir 3000 consoles in the four studios are connected to a central Route 6000 in a MCR via MADI. MADI provides a bidirectional audio connection between both ends. Consoles, cores and Route 6000 are networked via Eth-ernet. Studio 1 and Studio 2 share one news booth as described in example 1, Studios 3 and 4 do the same with the second one.

The functional principle of sharing audio signals between Studios 1 and 2 or Studios 3 and 4 is very similar to example 1, except that the direct audio tie lines between the studios and the router are replaced by MADI interconnec-tions. Shared signals are now ‘tunnelled’ through a central device.

This setup adds a couple of advantages to the installation. Via MADI, many more signals can be shared simultaneously than via an AES3 connection. These additional channels may be used to distribute the signals from News Booth 2 to Studios 1 and 2 as well. This enables Studio 2 to record a signal from Booth 2, while Booth 1 is at the same time used for the news with Studio 1. The setup also allows a very flexible emergency switch-over, since every studio can connect to any voice booth.

Studer RELINK


4.3 Example 3: Radio Broadcast and Production House This example shows a (radio-) broadcast house where production studios

and control rooms are located, in addition to the OnAir studios in the same building. The production studios (Drama A, Drama B and Auditorium) are equipped with D21m stageboxes connected to the Route 6000 in the MCR. In this way, not only the two Vista 5 consoles in the production control rooms can use mic signals from the stageboxes, but also the four OnAir consoles can use these signals and, if necessary, also get control of the mic parameters.

Studer RELINK


5 Operation

5.1 Signals to be Shared: Overview There is no limitation to input signals that can be shared between consoles.

5.2 OnAir5.2.1 Using Shared Signals

Shared signals supplied by other systems within the audio network can be assigned to faders to be mixed.

5.2.2 Mic Take-Over Procedure

The following scheme shows a take-over procedure of the ‘Mic 1’ signal between two consoles, ‘System A’ and ‘System B’

1 On both systems, the shared ‘Mic 1’ source is free. Both of them are already able to consume the signal of this source, but access to the signal parameters is not yet assigned.

Studer RELINK


2 The operator of System A touches the ‘FREE’ button and immediately gets access to the related microphone parameters. ‘FREE’ changes to ‘LOCAL’ and is displayed in green. The source-related parameters are indicated. The operator has access to phantom power, high-pass filter and the analog gain. On System B, the ‘FREE’ button has changed its colour to red, it indicates the device that now has exclusive access to the signal parameters.

3 The operator of System B wants parameter access now. He touches the red indicator. A confirmation window pops up, asking him to confirm or refuse taking over the signal parameter control from System A to System B. By touching ‘No’, the window closes and everything remains as it was before (2). Confirming the take-over by touching ‘Yes’ executes the parameter control transfer from System A to System B.

4 System A indicates a warning, telling the operator that control has been taken over by System B. Without affecting the take-over procedure, the operator of System A has to confirm the warning.

5 The ‘LOCAL’ indication of System A has switched from green to red, show-ing the new owner of the parameter control now. No further access to signal parameters is possible on System A. System B indicates that signal param-eter control is now available by a green ‘LOCAL’ button. All relevant signal parameters are accessible now, all having the latest values set by the control-ling system before.

6 The operator on System B manually releases the exclusive control of the signal parameters by touching the green ‘LOCAL’ button. Without any warning, the indicator switches to grey, and all parameters are now ‘FREE’ again.

5.3 Vista5.3.1 Input Patching

With SW V4.1, a new source and target navigator menu has been introduced. It still is a pulldown menu, but it showns not only local sources and targets, but also sources and targets of all systems connected via the network.

Shared inputs can be selected directly from any of the displayed systems. The sources of OnAir consoles – e.g. a DJ microphone - are appearing as ‘Logical Inputs’, and their output signals as ‘Master Outputs’.

Studer RELINK


5.3.2 Output Patching

‘Set Outputs’ activates all preselected patch points to outputs on remote sys-tems. This introduces an additional step in creating a patch connection, which the Vista SW did not know up to now.

The operator might want to switch several outputs to a different system (e.g. program outputs) at the same time. So when he is making the connections in the patch, they are marked in gray, indicating that the connection has not yet been established. Only when the ‘Set Outputs’ button is clicked, all the gray connections are set active at the same time. ‘Set Outputs’ only becomes active if some output patch connections are made to other systems.

This is only necessary when doing patch connections manually. When using snapshots, the connections are applied immediately.

There is now also a new Edit dialog that allows saving multiple output patches to shared targets as ‘Output Snapshots’. They must be given a name so that they can be recalled later from the lower right corner of the GC (graphic con-troller). An existing ‘Output Snapshot’ can be loaded as well, which means that the saved patch connections are not established but just shown in the gray, ‘pending’ state instead. In this state, the pending connections can now be edited and saved, e.g. under a new name.

Studer RELINK


5.3.3 Mic Take-Over Procedure

The following status diagram shows how the mic control take-over mecha-nism is realised in the OnAir3000. This has to be followed, since it is firmly implemented in the DNet code.

With the Vista desk, this dialog is handled in the channels Vistonics view in order to be able to link a number of channels and do the take-over handling for all of these channels at the same time (with a ‘gang’).

There is one difference to the OnAir behavior: When a mic source of another system is patched to a local input channel as long as the mic control is not taken by another desk (i.e., ‘free’ in the OnAir terminology), control is auto-matically given to the local Vista and the mic control parameters are displayed immediately.

Studer RELINK


There is a new parameter in the Vistonics view (Mic Ctrl) that allows setting the mic access control to ‘Free’, so that the mic can be controlled by other systems directly.

A description of how all the necessary states look like is given below. 1a First, no mic is connected to the channel. Then, a shared mic currently in use

by another OnAir or Vista console is patched to input channel manually:

Studer RELINK


1b First, no mic is connected to the channel. Then, a shared mic currently not in use by another OnAir or Vista console is patched to input channel manu-ally:

The same behavior is valid if one or more shared mics currently not in use by other systems is/are patched to the local input channel via a snapshot.

1c If one or several shared mics are used on other systems but then get patched to a local channel via a snapshot, the following message appears on the GC:

If confirmed with yes, the control for all the shared mics patched in the snap-

shot is taken over from the other systems. 2 A shared mic is patched to an input channel but then is taken over from a

different desk:

Studer RELINK


If this happens (on one single channel or also on several channels at the same time), a warning message appears on the GC screen:

This is the window that shows all I/O Sharing events. It disappears after a click on the OK button.

5.3.4 Vista Restrictions

• Signaling, such as red light or fader start, is not combined with I/O Shar-ing.

• Vista systems cannot have any ‘NETInputs’ configured (chapter 2.1.7). • 96 kHz sampling rate configurations on Vistas can only be used when no

OnAir console and no Router is involved in the Relink network. As long as only Vista systems are within the Relink network, 96 kHz configurations can be used. However, all Vistas then need to run at 96 kHz.

Studer RELINK


6 TECHNICAL DETAILS ON THE OnAir SIDE

6.1 OnAir Setup for I/O Sharing (for more details, refer to the OnAir 2500/3000 operating manual)

6.1.1 Define a Physical Connection

Using the configuration tool on the target system, select I/O Sharing - Physi-cal Connections and select an input with the Horizontal rotary encoder (HD Link In 7 in the example below). Then define a source for it by first touching the Source field that is, in our case, still empty (indicated by a ‘-’ dash).

A pop-up menu lists the names of all systems (in our case, System27 and Star DEMO 5OG) to select from, as shown above. After having selected System27, all its I/O frames (Int and, if available, Ext) will be listed. In our case, this is just one frame called System27, Int, as shown below.

After having selected an I/O frame, the labels of all available outputs are displayed.

Studer RELINK


Note: The definition must represent the actual physical (hard-wired) connections established by MADI, AES/EBU etc. wiring.

Select one of the outputs (System27, Int, Slot 8, AES, Ch. 1) to define the physical connection. It is displayed afterwards in the corresponding Source field, as shown below.

To save this physical connection, touch the Save IO Sharing button.

Undo a Physical Connection: In order to undo a physical connection, remove the existing relation between an input and an output of a neighboring system. Select an input whose Source parameter is to be cleared and touch the ‘-’ field. If the specified input is currently in use by a Net Input, the connection cannot be undone, and a user message is displayed.

Studer RELINK


6.1.2 Define Logical and Patch Inputs, Ext. PFLs, Ext. Monitoring Sources

Using the configuration tool on the target system, select I/O Sharing - Logical Connections - LogicalInputs (or PatchInputs, ExternPFLs, or ExternMonSrc) and select a logical input with the Horizontal rotary encoder (Logical In 2 in the example below). Then define a source for it by first touching the Source field that is, in our case, still empty (indicated by a ‘-’ dash).

OnAir 2500: Patch Inputs are not supported by OnAir 2500.

A pop-up menu lists the names of all systems that are connected via physical connections (in our case, System27 and Star DEMO 5OG) to select from, as shown above. After having selected System27, a list of source groups to select from pops up, as shown below.

When selecting, e.g., Logical Inputs of System27, the available inputs are displayed, as shown in the next screenshot.

Studer RELINK


As MD 2 is the desired input in our example, touch the System27, MD 2 entry. After that, the CD 2 input label changes to MD 2, as shown below. The MD 2 audio signal is immediately available on the target system now (provided that sufficient physical connections are available; if not, the label would indicate *MD 2). It is routed, however, only if the connection is static or the Net Consumer is currently active (i.e. assigned to a channel strip, selected as a monitoring source, etc.).

In case you should want to change the Net Mode from dynamic to static, then touch the corresponding Dynamic field and select Static from the pop-up menu.

In order to save this input definition, touch the Save IO Sharing button.

Note: As can be seen on the previous page, not only logical inputs of the source system may be selected, but also external monitoring sources, external PFLs, master outputs, send channels, subgroups, monitor sends, and Net inputs.

Studer RELINK


6.1.3 Define Net Inputs

In two-step I/O sharing, Net Inputs must be defined in order to make a neigh-boring Net Source available, e.g. on the Star DEMO 5OG system. Start the configuration tool on the target system and select I/O Sharing - Net Inputs. When selecting the Net Source parameter, the configuration tool shows a pop-up menu listing the names of all systems that can be reached by physical connections. Net Input connections are always static.

After having selected a system, the Net Source groups pop up. Select one of them (e.g. Extern Monitoring Source).

Then a list of all possible Net Sources pops up (in our example, all available external monitoring sources). Select one of them, e.g. OFF AIR.

Studer RELINK


The label of the specified Net Source is copied to the Net Input, and audio will be connected immediately. If there is any problem connecting to the source system, the label indicates an asterisk (*), as shown below.

To save this Net Input definition, touch the Save IO Sharing button.

Release a Net Input: To release a Net Input, remove the existing allocation to the Net Source of the neighboring system. Select a Net Input and clear its Net Source parameter by touching the ‘-’ field.

If the specified Net Input is currently in use (e.g., on-air or assigned to a fader strip), it cannot be released, and a user message is displayed.

Note: As can be seen on the previous page, not only logical inputs may be selected as Net inputs, but also external monitoring sources, external PFLs, master outputs, and monitor sends.

Studer RELINK


7 Technical Details on the Vista side

7.1 Setting up the Vista for I/O Sharing7.1.1 ConfigTool for DNet Applications

For configuring the tie lines necessary for I/O Sharing on the Vista system, we use the ConfigTool for DNet Applications known from the OnAir product range. This program now needs to be installed on the Vista’s control computer (C:\Release ConfigTool\ConfigTool.exe). In the same folder there needs to be a file named container.ini with setup information for this DNet ConfigTool. Here is an example of the container.ini file for the ConfigTool:

############################################################################ container.ini: Necessary for initialization of each container (.exe)## Digital Mixing Console: VISTA# Studer Professional Audio GmbH, Regensdorf, Switzerland## Last modification : Sep, 1st 2006# Compatible with OATreeLib : V2.1# Author : SIA## Rules:# ======# - allways leave one blank before and after the ‹=› (e.g. systemid=1 NO!)# - never change the left expression# - the right expression of systemid, containerid, systemname# and containername MUST be defined# ##########################################################################

# The systemid identifies the mixing console system to which this container# belongs to. The systemid is a unique number within a network.# The serial number must be in the range 1..255

systemid = 36 � this needs to be a unique number

# The systemname identifies the mixing console system in a readable way# and must be unique within a company resp. network. It is recommended# not to use more than 8 characters due to visualization aspects.# «Undefined» is not allowed!

systemname = «ConfigTool» � the name of the system

# The containerid identifies this container # and must be unique within the mixing console system# This id is fixed to ‹10› (CORE) for all VISTA desks

containerid = 20 � ‚20’ is always standing when the container.ini is belonging to a configtool

Studer RELINK


# The containername identifies this container in a readable way# and must be unique within the mixing console system. It is recommended# not to use more than 8 characters due to visualization aspects.# «Undefined» is not allowed!

containername = «Config» � the name of the container

# Multicast# -----------# If you use IGMP multicasts instead of broadcasts in your network,# you have to uncomment the the lines below. It is possible, that a # container is member of one or more than one multicast groups.## NOTE: For an optimal performance, make sure that all network ressources# (Switches, Routers...) support IGMP.## NOTE: To avoid IP conflicts, check the available addresses for# multicast groups (www.iana.org). Use preferable addresses from the# local scope (239.255.0.0/16) described in RFC 2365.## NOTE: If the multicast should reach computers beyond the local subnet# Set MulticastTimeToLive > 1 (1 is default)

# MulticastGroup = 239.255.0.1# MulticastGroup = 239.255.0.2# MulticastGroup = 239.255.0.3# MulticastTimeToLive = 10

# Multiple Network Adapters# ---------------------------------# When more than one network adapter is enabled on the computer, the MAC Address has to be specified## MAC = 00-1A-A0-B9-F9-88

Note: There needs to be a second container.ini file on the Vista’s control computer – the one which is belonging to the mixing console application (see chapter 7.1.4)

Start ‘Config tool for DNet applications’ in the Vista console’s C drive (C:\Release ConfigTool\ConfigTool.exe)

Studer RELINK


Select one of the DNet systems availabe in the network, select the appropriate Vista system.

If the Vista or the other connected systems are not appearing, please refer to chapter 7.1.2 to verify the settings in the Container.ini file.

In the configuration tool, go to Physical Connections. Under Destination all HD links within your system are listed.

Select the physical inputs to be used as tie lines. Once they are configured as tie lines, they will no more be visible in the Vista general patch. Configuration always takes place on the consumer system (target system). Only the tie line inputs need to be configured, i.e., the tie lines that are directed towards our system. The tie lines that go away from our system are configured as inputs on the other systems, such as the router.

Select the appropriate system (e.g. the Star router, as shown below):

Studer RELINK


In the next step a D21m frame is selected (the external frame Ext in our example:

Now select the appropriate interfaces (e.g. MADI), one by one, for every single physical audio connection.

When finished, click the Save IO Sharing button at the right-hand edge of the Configuration Tool GUI.

This procedure only needs to be done once, during system setup. All these tie line configuration settings are saved on the consumer side and will remain after a system restart.

Studer RELINK


7.1.2 Restricting Shared I/O

Per default, all sources and targets attached to a Vista system can be seen and used by other systems that are part of the I/O Sharing network. Access to these I/Os may be restricted; they can then be used on the local Vista system only, but are not available to other systems within the network.

This is done with a text file containing a list of fixed labels of the I/Os that should be visible to others; the file must be named SharedPatches.iosharing and saved in the folder of the VMC configuration which it is valid for, such as D950SystemDB\Config1.

SharedPatches.iosharing Example: ... I 17 B 1 Ch17 I 18 B 1 Ch18 I 19 B 1 Ch19 I 20 B 1 Ch20 I 21 B 1 Ch21 I 22 B 1 Ch22 I 23 B 1 Ch23 I 24 B 1 Ch24 ...

Notes: The I/O configured as tie lines must also be added in this file. If no file with this name is found in a configuration folder, all I/Os of this

Vista system will be available for networked access.

7.1.3 Configuration Changes

EveryVMC configuration change in a Vista console has an effect on the other consoles using this Vista’s I/O at the same time. This means that an I/O can disappear and then reappear in a different constellation.

When using a file named CommonSharedPatches.iosharing located in the D950SystemDB folder, a number of sources and targets can be defined as I/O that must not change. This is useful for inputs or outputs that remain the same throughout all VMC co nfigurations on the Vista. It contains a list of the fixed labels of the desired I/O.

CommonSharedPatches.iosharing Example: ... I 65 B 1 Ch65 I 66 B 1 Ch66 I 67 B 1 Ch67 I 68 B 1 Ch68 I 69 B 1 Ch69 I 70 B 1 Ch70 I 71 B 1 Ch71 I 72 B 1 Ch72 ...

This file needs to be created manually. If no file with this name is found in a configuration folder, all I/O will be reinitialized by a configuration change.

Studer RELINK


7.1.4 Container.ini

The container.ini file for the Vista system is found in C:\D950System\. This file contains some important entries making the I/O Sharing work. Here a list of these entries:

############################################################################ container.ini: Necessary for initialization of each container (.exe)## Digital Mixing Console: VISTA# Studer Professional Audio GmbH, Regensdorf, Switzerland## Last modification : Sep, 1st 2006# Compatible with OATreeLib : V2.1# Author : SIA## Rules:# ======# - allways leave one blank before and after the ‘=’ (e.g. systemid=1 NO!)# - never change the left expression# - the right expression of systemid, containerid, systemname# and containername MUST be defined###########################################################################

# The systemid identifies the mixing console system to which this container# belongs to. The systemid is a unique number within a network.# The serial number must be in the range 1..255

systemid = 35 � this needs to be a unique number

# The systemname identifies the mixing console system in a readable way# and must be unique within a company resp. network. It is recommended# not to use more than 8 characters due to visualization aspects.# «Undefined» is not allowed!

systemname = «Vista5» � the name of the system

# The containerid identifies this container # and must be unique within the mixing console system# This id is fixed to ‹10› (CORE) for all VISTA desks

containerid = 10 � ‚10’ is always standing when the container.ini is belonging to a Vista desk

# The containername identifies this container in a readable way# and must be unique within the mixing console system. It is recommended# not to use more than 8 characters due to visualization aspects.# «Undefined» is not allowed!

containername = «Desk» � the name of the container

Studer RELINK


# Multicast# ---------# If you use IGMP multicasts instead of broadcasts in your network,# you have to uncomment the the lines below. It is possible, that a # container is member of one or more than one multicast groups.## NOTE: For an optimal performance, make sure that all network ressources# (Switches, Routers...) support IGMP.## NOTE: To avoid IP conflicts, check the available addresses for# multicast groups (www.iana.org). Use preferable addresses from the# local scope (239.255.0.0/16) described in RFC 2365.## NOTE: If the multicast should reach computers beyond the local subnet# Set MulticastTimeToLive > 1 (1 is default)

# MulticastGroup = 239.255.0.1 � Multicast groups should all be disabled# MulticastGroup = 239.255.0.2# MulticastGroup = 239.255.0.3# MulticastTimeToLive = 10

# Multiple Network Adapters# -------------------------# When more than one network adapter is enabled on the computer, the MAC Address has to be specified#MAC = 00-AA-11-BB-22-CC � in case of a Vista 6/7/8 with multiple network adapters, they need to be specified here

7.1.5 D950System.ini

The following entry needs to be added in the D950system.ini file: IsRelinkActive=Yes

Studer RELINK


7.2 Tie Line Management On every Vista console, tie lines need to be configured with the OnAir con-

figuration tool. They may be any type of I/O, the most efficient of them are HD links giving 96 channels in both directions per Cat5 cable pair. Further-more, MADI interfaces with a maximum channel capacity of 64/64 are quite popular for tie lines. MADI tie lines may also be configured to use less than 64 I/O – any desired number smaller than 64. AES/EBU or Line interfaces can also be used as tie lines if only a small number of audio channels needs to be shared, such as for transmission lines.

Tie line management is dynamic, therefore only the maximum number of audio channels used simultaneously needs to be considered.

The total amount of configured tie lines is displayed in the I/O Sharing area of the general patch in the GC, as well as the number of the currently free tie lines.

7.3 Control Network All systems that need to be part of the I/O Sharing network need to be inter-

connected via Ethernet. On the Vista side, it is always the desk that needs to be networked.

7.3.1 Vista 5

Vista 5 is by default equipped with two network ports: Primary LAN and Secondary LAN, the sockets thereof can be found on the rear side of the desk.

The simplest way is to use the Secondary LAN port for I/O Sharing. In that case, the Primary LAN port can still be wired directly to the bridge card of the SCoreLive. In case of cable redundancy to the bridge card (both ports of the desk are wired to both ports of the bridge card in parallel), an Ethernet switch needs to be placed between Secondary LAN port and bridge card. From this ethernet switch, the connections are made to all the other I/O Shar-ing devices.

In case the I/O Sharing network only consist of two Vista 5 consoles, also a X-over network cable between both Secondary LAN ports of the two con-soles could be used instead of an Ethernet switch.

Studer RELINK


7.3.2 Vista 6, 7, 8

Since Vista 6, 7 and 8 are not equipped with a second network port per default, an Ethernet switch needs to be used.

In the case of a Vista 8 with a redundant control system it is recommended to connect the Ethernet switch between the network port of the main control system and the bridge card of the ScoreLive. The network port of the redun-dant control system would then still be connected straight to the second port of the bridge card.

• Vista desk networked (Ethernet) • Tie lines between cores (MADI, AES, or HD Links) • DNET technology from OnAir product range • Setup with the OnAir configuration tool also on the Vista side.

7.3.3 IP Addresses

The IP addresses of the SCore Live bridge cards should not be changed. They are always set to 192.168.1.60 for the primary network port, and to 192.168.2.60 for the secondary network port.

Please refer to chapter 9 for network examples with Vista and OnAir consoles in a RELINK setup.

Note: In case of a network design where more than one Vista console are com-municating with its SCore through one and the same Ethernet switch, the IP addresses may be changed as with the OnAir console range. But then the Vista’s D950System.ini files need to be adapted accordingly.

Studer RELINK


7.4 Audio Sync for all Systems All systems being part of the network that can exchange audio via tie lines

must be properly synchronized. The best option to do this is having a Studer D21 MasterSync unit feeding wordclock in a star configuration to all the systems involved.

If a single system cannot be synchronized, either AES/EBU cards with SFCs or analog cards have to be used for tie lines.

Studer RELINK


8 Glossary Physical Connection Hard-wired connection between two SCores; for these, MADI, ADAT, AES/

EBU, or even analog connections may be used. Logical Connection Connection between two SCores running on a hard-wired Physical Con-

nection; may be defined as static (permanently reserved) or dynamic (used by the system only as long as required). For Net Inputs, only static Logical Connections are allowed.

Logical Input The term Logical Input not only comprises the audio signal of this input but also its signal processing parameters, such as EQ, filters, dynamics, etc.

Net Input Object on the Star System that is provided to other systems connected to the Star System.

Net Source Object on the Source System that has specified a local source (e.g. input, master, external PFL input, monitoring source, etc.).

Net Consumer Object on the Target system to which a mono or stereo signal must be assigned (e.g. input, master, external PFL input, external monitoring source, etc.).

Net Consumer Active A Net Consumer is called active as long as it is using the allocated Net Source.

Consumer Type: is active if the corresponding Net Consumer is:

Net Logical Input assigned to a channel strip, or selected as a monitoring source, or assigned to a logical output via output routingNet Ext. Monitoring Source selected as a monitoring source

Net Ext. PFL switched to at least one PFL busNet Talkback switched to at least one talkback destination

Studer RELINK


9 Recommended Network Setup Examples

9.1 Vista 8 and Vista 5 – with a Switch

Vista 5 Desk

SCoreLive Vista 5

192.168.1.125 „Primary Lan“

Vista 8 Desk

SCoreLive Vista 8

192.168.1.128 (existing network port1)

192.168.2.125 „Secondary Lan“

192.168.1.60 Bridge1 Port1192.168.2.60 Bridge1 Port2

192.168.1.60 Bridge1 Port1

Ethernet Switch

DAW

192.168.2.a

HiQnet Device

192.168.2.b

Plugin PC

192.168.2.c

Setup Notes :

The recommended setup is to use 2 network ports in the Vista 8 – then, the .1 subnet remains unaffected for the bridge links. RELINK and other applications are then using .2 subnet.

The addressing of the nodes in the .2 subnet – 192.168.2.a-c – need to be unique numbers, different from 128 and 125 used on the Vista consoles.

The Vista 5 IP addresses marked red, 192.168.1.125 are manually changed from its original setting 192.168.1.128.

The subnet mask per default is 255.255.255.0 .

Please note that with the Vista consoles when more than one network port is configured, the MAC address of the additional network port(s) need to be entered into the container.ini file of the Vista ! (when using a redundant control system – there is always an additional network port:the USB network connection between main- and redundant control system.) The MAC address of any network adapter can be shown withthe „ipconfig /all“ command from a dos window.

192.168.2.128 (additional network port2)

(192.168.1.60 Bridge2 Port1)(192.168.2.60 Bridge2 Port2)

Studer RELINK


9.2 Vista 8 and Vista 5 – Peer-to-Peer

Vista 5 Desk

SCoreLive Vista 5

192.168.1.125 „Primary Lan“

Vista 8 Desk

SCoreLive Vista 8



192.168.1.60 Bridge1 Port1192.168.2.60 Bridge1 Port2

192.168.1.60 Bridge1 Port1

Setup Notes :


The Vista 5 IP addresses marked red, 192.168.1.125 are manually changed from its original setting 192.168.1.128.

The subnet mask should be 255.255.255.0




Studer RELINK



Vista 5 Desk

SCoreLive Vista 5

192.168.1.125 „Primary Lan“


192.168.1.60 Bridge1 Port1

Setup Notes :

The Vista 5 IP addresses marked red, 192.168.1.125 are manually changed from their original setting 192.168.1.128.



Vista 5 Desk

SCoreLive Vista 5

192.168.1.128 „Primary Lan“


192.168.1.60 Bridge1 Port1

Studer RELINK



Vista 8 Desk

SCoreLive Vista 8


192.168.1.60 Bridge1 Port1

Vista 8 Redundant PC

192.168.2.60 Bridge1 Port2

Setup Notes :








Vista 8 Desk

SCoreLive Vista 8


192.168.1.60 Bridge1 Port1


192.168.2.60 Bridge1 Port2





Studer RELINK


9.5 Vista 8, Vista 5, Route 6000, OnAir 3000

Route 6000

192.168.x3.10

Vista 5 Desk

SCoreLive Vista 5

192.168.1.125 „Primary Lan“

Vista 8 Desk

SCoreLive Vista 8


192.168.x5.10 „Secondary Lan“

192.168.1.60 Bridge1 Port1


192.168.2.60 Bridge1 Port2

192.168.1.60 Bridge1 Port1

Ethernet Switch

DAW

192.168.0.a

HiQnet Device

192.168.0.b

Plugin PC

192.168.0.c

Setup Notes :

OnAir consoles have the following addressing convention: 192.168. x.y, where x is the SystemID, and y is the containerID. With OnAir consoles the SystemID is derived from their specific serial number (S/N mod 256 = SystemID). The containerID is always 10 for a Core and 100 for a desk.

To allow this addressing scheme with Vista consoles as part of the network, subnet masks need to be set to 255.255.0.0 on all involved equipment.

The recommended setup is to use 2 network ports in the Vista 8 – then, the .1 subnet remains unaffected for the bridge links.

When OnAir consoles are part of the network, we can also use the OnAir addressing convention on the Vista consoles. With Vista consolesthe containerID is always 10.

Please note that with the Vista consoles, when more than one network port is configured, the MAC address of the additional network port(s) need to be entered into the container.ini file of the Vista! (when using a redundant control system – there is always an additional network port:the USB network connection between main- and redundant control system.) The MAC address of any network adapter can be shown withthe „ipconfig /all“ command from a dos window.

All other PCs in the network can have an address in the subnet 0 : e.g. 192.168.0.a-g . This clearly distinguishes them from consoles.

192.168.x4.10 (additional network port2)




OnAir 3000Main Screen

OnAir 3000Core

192.168.x1.100

192.168.x2.10

Route 6000 PC

192.168.0.d

Studer RELINK


Studer RELINK


davenealRectangle

Studer RELINK


davenealRectangle

RELINK (Resource Linking) Product InformationContents1 - Strategic Concept2 - Functional Concept2.1 - I/O Sharing Definitions2.1.1 - Single-Step I/O Sharing2.1.2 - Two-Step I/O Sharing2.1.3 - Ethernet - TCP/IP Network2.1.4 - System2.1.5 - NETSource2.1.6 - NETConsumer2.1.7 - NETInput2.1.8 - Net Mode / Static/Dynamic Connections2.1.9 - Physical Connections2.1.10 - Logical Connections2.1.11 - Active

2.2 - Signaling and Remote Parameter Control2.3 - Signal Routing

3 - Topologies3.1 - Peer-to-Peer Setup3.2 - Triangle Setup3.3 - Star Setup3.4 - Functionality

4 - Application Examples4.1 - Shared News Booth4.2 - Shared News Booths, Central Router4.3 - Radio Broadcast and Production House

5 - Operation5.1 - Signals to be Shared: Overview5.2 - OnAir5.2.1 - Using Shared Signals5.2.2 - Mic Take-Over Procedure

5.3 - Vista5.3.1 - Input Patching5.3.2 - Output Patching5.3.3 - Mic Take-Over Procedure5.3.4 - Vista Restrictions

6 - Technical Details, OnAir6.1 - OnAir Setup for I/O Sharing6.1.1 - Define a Physical Connection6.1.2 - Define Logical and Patch Inputs, Ext. PFLs, Ext. Monitoring Sources6.1.3 - Define Net Inputs

7 - Technical Details, Vista7.1 - Setting up the Vista for I/O Sharing7.1.1 - ConfigTool for DNet Applications7.1.2 - Restricting Shared I/O7.1.3 - Configuration Changes7.1.4 - Container.ini7.1.5 - D950System.ini

7.2 - Tieline Management7.3 - Control Network7.3.1 - Vista 57.3.2 - Vista 6, 7, 87.3.3 - IP Addresses

7.4 - Audio Sync for all Systems

8 - Glossary9 - Recommended Network Setup Examples9.1 - Vista 8 and Vista 5 - with a Switch9.2 - Vista 8 and Vista 5 - Peer-to-Peer9.3 - Vista 5 and Vista 5 - Peer-to-Peer9.4 - Vista 8 and Vista 8 - Peer-to-Peer9.5 - Vista 8, Vista 5, Route 6000, OnAir 3000

Documents

Product Information…Studer RELINK 6 SW V2.0 Date printed: 13.03.09 2.1.7 NETInput (not available for Vista consoles) A NETInput is a virtual object in a two-step I/O sharing setup