The avalon playback system is made of five main parts:
  • The server core. This is the server executable. It handles the configuration, manages drivers, services, channels and threads.
  • Plugins. Avalon uses the abstract terminology 'module' to describe a datasource/datasink. Anything is allowed here (files, programs, ...). Although - to attach the module to the server a plugin is needed for the server to interpret the file format or the foreign data stream.
  • The device drivers. In order to support arbitrary devices, a device driver model has been implemented. Plugins don't care about where their data will be streamed to. Server configuration takes care about the correct routing.
  • The remote control. By making the user interface external, the system lets the user choose, which look and feel he/she wants to use. The open protocol allows anything from simple PC-based programs to complete control desks.
  • The ASX Protocol. The Avalon Server eXchange Protocol is used by the server core, plugins, remote controls and drivers to communicate with each other.

Server core

The core manages all attached components and routes messages. It maintains several threads waiting for incoming connections. For new connections coming from remote controls, a separate thread gets launched. This thread will be associated with a module and with this implicitly with a pluging handling the module. The remote control can then control the run parameters (start/stop/continue, ...) of the module.
For data streaming, the module has to open a (or multiple) channels to server services. Data is then exchanged across this channel. The server cares for service availibility and message routing.
Through configuration, services can be connected to devices located inside a unit. Every unit is managed by a device driver. A driver can handle multiple units, a unit can be made of multiple devices.


In order to support arbitrary data sources and data sinks, the server has a plugin interface. Plugins handle file formats, attach to 3rd party software like renderers or implement programmed animations like games. A hierachical 3D rendering pipeline for vector graphics used by laser systems, located in a shared library, already comes with the server, ready to be used by plugins. The plugin interface is a powerful architecture. To support a new file format, all that has to be written is a plugin. The architecture allows for chaining of plugins to filter data or to extend the versatility by including other plugins.


A true multimedia system must be able to talk to a vatiety of hardware doing the I/O. For portable systems there further is the requirement to support different architectures. For Avalon this problem has been solved through a device driver architecture. Drivers manage multiple units containing multiple devices. Server services can be connected to each of the devices. A network driver (like the StageNet driver) for example manages all units located in the network. A driver for the local PC-Computer would manage the PC-Computer unit and with this all it's devices (like audio, Serial ports, ...). For ease of maintenance, drivers are located in dynamically loaded shared libraries.

Remote control

Having the operators interface being implemented outside the playback system was a main goal right from the beginning. Different people like different user interfaces and different companies like to present different look and feels to their customers. When using a system - what counts in the end is the position, color and shape of buttons and menues. Technical features lose of their importance.
Writing remote controls for the Avalon Server is easy. Just open a TCP connection to the server and send a packet telling it which module to start. This scheme can be used by pure software remotes or software/hardware solutions like control desks. Because of the nature of TCP as a network protocol, it doesn't matter if the server process and the remote run on the same machine, if they are connected through an ethernet or if they are running on machines located somewhere in the internet. A single server can handle any amount of remote controls running any amount of modules.
Currently the server comes with a single, powerful remote control written in Java. This one supports all available system features.

ASX Protocol

To connect all the pieces, the Avalon Server eXchange Protocol has been defined. The protocol is built around datachunks carrying routing information, a size and a content type ID. The server core routes the chunks to their destination, where their content gets interpreted. For remote controls and plugins, a java implementation of the protocol comes with the server package.


The Avalon playback system is currently available as binaries for the Linux and OS/2 operation systems. Most of the system is highly portable and can be easily adapted to other environments.
To scale costs, licensing is on a per-unit base. This, while offering all the flexibility, reduces the cost of ownership for small systems and scales reasonable for complex systems, offering its full power in routing and handling of multiple data streams. The server itself is for free. To activate the use of a particular unit, a key has to be requested. The costs of the keys vary on the power of the unit to be used with the server.

Licensing fees

Not yet available, please ask


Not yet available, please ask

Download area

Not yet available, please ask