Compilation, DSP and Partitions
Click here to see this page in full context

 

Compilation and Partitions

Introduction

As part of implementing a Tesira system there is a requirement to configure and layout the component objects in order to achieve audio, video and logic rules to meet a design brief. Once the components have been placed in the layout and wired (connected) together the Tesira Compiler is tasked with allocating adequate DSP resources to the proposed configuration. A number of design tools are provided to facilitate this. The following items are reviewed in this section:

Partitions

Partitions allow a configuration file to be segmented into different sections. Each partition is an independent entity that is displayed on a separate tab in Tesira software, and partitions can even be updated with new configuration files without interrupting the AV content being processed by other active partitions.

Defining the boundaries between partitions is completely up to the system designer, and there are virtually no restrictions on how the boundaries can be constructed. Common methods for defining partition boundaries include:

  1. Basing partition boundaries on physical boundaries. For example, different rooms in a facility could occupy their own partitions. This method is particularly useful, since the configuration of each room could be updated without interrupting the audio or video in other partitions. Additionally, since different physical spaces often don’t need to be delay equalized, allocating them to different partitions makes it easier to de-couple different acoustic spaces.
  2. Using partitions for organizational purposes. For example, all input processing could be located in one partition, mixing and routing in another partition, and output processing in another partition. For large and complicated configurations, this can simplify navigation of the system.
  3. Basing partition boundaries on hardware boundaries. For example, each Tesira server in a system could occupy its own partition. This method can also help with organization and navigation for systems in which different servers share very few responsibilities with one another.
  4. A shared mix of the above

Restrictions and Limits

There are very few restrictions on how partitions can be applied to a configuration. A single partition may span multiple Servers, and each Server may contain multiple partitions.

Each Tesira configuration may be divided into a maximum of 32 partitions.

Sharing Audio Between Partitions

All partitions in a configuration can optionally share audio and/or logic signals with one another through the use of Partition Connectors. Audio content can be shared from video partitions for processing and output, and optionally routed back in to an AV stream on a Video partition if desired. Partition Connector Transmitters and Receivers can be linked to one another either via the Partition Connector Receiver control dialog or via the System View window. The relationship between different partitions is summarized on the System Overview tab.

As described above, partitions can be updated independently without affecting the AV content running in other partitions. However, it is important to be aware that making a change to one partition can occasionally necessitate an update in another partition. This generally occurs in partitions that share audio or video content with one another. The reason this may happen is that partitions that share audio content usually need to be delay equalized with each other. Therefore, if a change is made in one partition which requires an update to the delay equalization requirements in another partition, then both partitions will require an update. For this reason, Tesira offers four delay equalization modes to control how independent partitions are equalized by default. See Delay Equalization  for a description of these modes.

Once a system design is created (components placed & connected), the system can be compiled by selecting Compilation from either the System Menu or the Standard Toolbar. Compile provides system design analysis and calculates DSP processing requirements. Compile also makes initial determinations of quantity/type of Tesira® devices needed, AVB and CobraNet® channel assignments, allocation of DSP resources, and I/O channel number assignments. In addition, Compile will provide indication of system design errors.

A system design file must be compiled before it can be sent to Tesira devices.

Compilation

The Compiler is a feature of Tesira software that analyses and validates the layout, calculates I/O and DSP processing requirements and makes an initial determination of the number and type of Tesira hardware needed. It attempts to find the minimum hardware and the lowest priced solution that would still realize the design. It also attempts to minimize the number of DSP cards and network connections. Additionally, a Compile will provide indication of system design errors via a compilation report in the Output View. Finally, a Compile will perform automatic Delay Equalization on all audio paths, according to the Delay Equalization settings found under the General Settings section of the Document Settings control dialog window, which is accessed via the Options item in the Tools menu.

Compiling Single or Multiple Partition Configurations

Compile is initiated from the Compile or Compile All buttons in the Standard Toolbar, or from the Compile Active Partitions, Compile Uncompiled Partitions, Recompile All Partitions or Perform Global Optimization under the Compilation section in the System Menu.

  1. Compile Active Partitions - Compiles only the currently active partition.
  2. Compile All Uncompiled Partitions - Compiles all uncompiled partitions.
  3. Recompile All Partitions - Compiles all partitions, even if they have been already compiled but does not optimize I/O.
  4. Perform Global Optimization - Compiles all uncompiled partitions and analyzes the compilation results to find an equivalent, equipment allocation of a lower cost, if one exists. By default, the compiler finds an optimum equipment list for each partition in the system individually, but the accumulated result of this may not be cost optimal across the entire configuration, particularly in systems having many partitions. Perform Global Optimization may add or remove hardware from the Equipment Table if necessary. Devices in the Equipment Table with serial numbers assigned (physical devices) will not be removed by this optimization. Likewise, devices having DSP objects with fixed allocation will not be removed. If Global Optimization finds an improvement, the equipment table will be updated, and the entire layout will be recompiled. If no improvement is found, the previous compilation results are kept.

Compilation Order of Partitions

Tesira software compiles each partition individually, and partitions to be compiled will be processed in numerical order by default.

Occasionally, compiling partitions in numerical order can lead to undesired results or a compilation failure. For instance, the compiler might fully allocate I/O blocks to a unit in partition one so that there is no room for more I/O blocks in that unit. If subsequent partitions have I/O blocks that are fixed in the same unit, the compilation may fail.

For this reason, Tesira software allows to change the compilation order of partitions. This allows partitions to be compiled in a desired order, and may help to resolve issues like the one described above. It can also be helpful to compile partitions which have large mixer blocks before other partitions, to prevent splitting of large mixer blocks over several DSP cards.

A compilation summary can be viewed in the Output View Toolbar.

DSP resource

Once Compiled the DSP Resources being used by a given layout will be shown in the DSP Resource docking window. The resource shown is based on the DSP cards being used. Depending how the component objects have been assigned to the hardware via the equipment table or via the initialization dialog Equipment type filter will dictate the required DSP resources.

The DSP Resources Tab will give detailed information on the DSP being used in a compiling layout. It will show:

DSP Usage by Partition

The DSP resources Usage by Partition table sums the required resources for each block of a partition if the block would be included in a compile. This calculation is made live as lines are connected/disconnected.

DSP Usage by Device

The DSP resources chart describes usage per device. If some partitions are not compiled the Usage by Device chart will only show information for the partitions that have been compiled. When the compiled partition set is altered (line added/removed), the DSP resource allocation for that partition is removed until the next compilation.

Hardware DSP Chip resources

Context menu DSP resource

When selecting one or many component objects in the layout, the right-click context menu has a DSP Resource indicator which provides indication of DSP resources required. The component object is only required to be placed in the layout, and does not need to be part of a valid compilation.

Delay Equalization and DSP resource

Delay Equalization maintains synchronization between signals that have different propagation times. As the function of Delay Equalization is to insert Delay in the audio path it can impact the DSP resources available to the compiler. For very complex designs, there are some adjustments that can be made to optimize the Delay Equalization and DSP resources. Most compilation will succeed without requiring any user adjustments. Please review the Delay Equalization section for more details.

DSP Usage variations

If using the same system layout file on different PC's the DSP allowance slider in Document Settings will stay with the file and display the same on both machines.

There will also be variations of DSP usage if the exact same software version is not used. The DSP usage may also change between two versions of the software. If a previous layout was compiled in a different version of software the DSP algorithms used for blocks may have changed slightly.

In some scenarios, there may be slight differences in the DSP usage totals of the partition and device summary on the DSP Resource Tab. For  example - component objects such as large mixers may need to be broken across several DSP's in a DSP-2 card. The partition table doesn't factor this in, but a full compile does, so there might be a slight discrepancy in this particular case.

Hardware Allocation

The compiler will allocate I/O blocks to Tesira hardware according to the type of input or output and the Equipment Type setting (for applicable I/O blocks).  If an I/O block cannot be placed into any available hardware unit in the Equipment Table, the Compiler may add devices to the Equipment List in accordance with the Device Selection settings in the Application Settings > Compile Options control dialog window, which is accessed via the Options item in the Tools menu.

I/O Blocks and DSP objects can be manually allocated to units in the Equipment Table by using the Allocated To Unit and Fixed In Unit settings in the DSP Properties tab in the Properties window of each block. If an allocation is made and Fixed In Unit is set to True, the Compiler will attempt to use that allocation in the compilation process. The programmer may wish to do this if certain pre-determined I/O allocations are desired.

Equipment Type

The Initialization dialog for processing blocks that can be added to configurable devices.

Equipment type

Details

Autoconfigure

Will associate the block to a device in the equipment table that achieves the functions based on lowest cost.

Server

Will associate the I/O block to a Tesira Server class device

Rack-Mount Expander

Will associate the I/O block to a Rack-Mount Expander class device

Remote Expander

Will associate the I/O block to a Expander class device

Forté

Will associate the I/O block to a TesiraFORTÉ class device

Lab.Gruppen Amplifier

Will associate the Input block to a Lab.Gruppen Amplifier class device

Tesira Amplifier

Will associate the Input block to a Tesira Amplifier class device

Video

Will associate the I/O block to a TesiraLUX class device

 

The Equipment type available will adjust depending on the channel size, type of the block and if the block will reside in a audio or video partition.

For example a Lab.Gruppen Amplifier will only support an Input block up to 4 channels. Please review the Device Roles in a system section for more details.

Device and channel Assignment

Once a unit allocation has been made for each I/O block, it will be assigned a Device I/O port, which is the physical connector on the hardware device that corresponds to each software I/O object. If Fixed In Unit is set to True, the Device I/O port can be user specified in DSP Properties in the Object Properties window. The port is specified by its slot number first, then by the channel on the card in that slot. For example, a Device I/O of 4.2 would be a port located at channel 2 of the I/O card in slot 4.

Tesira SERVER, SERVER I/O TesiraFORTÉ, Tesira Amplifier devices are viewed by the Compiler as either a:

Due to the complexities and scale of Tesira the compiler will only guarantee not to move channel I/O around if you have a physical unit (I.E. assigned S/N in the equipment table) and have ‘fixed in unit’ on the software I/O blocks set to True.

The compiler rules may have been adjusted between software and firmware version. This means that after a firmware update a recompile may be required. It may also mean that if a Physical device is not specified there might be a change to I/O channel assignments.

If you have logical devices or the physical device I/O is not fixed in unit, the compiler may reallocate I/O channels every time you Compile or Recompile all. The recompile all invokes compilation of each partition in a specified order and will un-compile and recalculate. This may mean that if you reorder partitions or add I/O to certain partitions the channel I/O numbers will likely change / move. So in Tesira, in order to never have the I/O change the software must have a physical device and the I/O must be fixed in unit.

The compiler will place cards into a configurable chassis (SERVER, SERVER I/O, EX-MOD and Tesira Amplifier) in the same order specified in the Biamp order form (or as it is done in the field). If these orders always coincide, the substitution of a physical device for a logical one will never shift any cards and therefore the compilation will stay valid. If some additional cards are discovered in the physical device, the compilation will stay valid.

While the card order for the compilation process is irrelevant as the compiler can work with cards placed in any order, it is strongly recommend that any I/O cards should be in the factory specified order.

The SERVER I/O will support cards in different slots. The cards themselves will not work if placed in an inappropriate slot; the Compiler will only allow the correct card in the appropriate slot.

 Slot SERVER IO Card Type
14 SNC-1
13 AVB-1, DAN-1 or SCM-1
12 DAN-1, SCM-1 or card from below
11 DAN-1, SCM-1 or card from below
10 SVC-2 or card from below
9 STC-2 or card from below
8 SOC-4 or card from below
7 ...
6 ...
5 ...
4 ...
3 SNC-4 or card from below (i.e SIC-4 or SEC-4)
2 SEC-4 or card from below (i.e. SIC-4)
1 SIC-4

 

NOTE: The SERVER I/O has a hard limit of a maximum of