|Serveur © IRCAM - CENTRE POMPIDOU 1996-2005.
Tous droits réservés pour tous pays. All rights reserved.
The Ircam ``Real-Time Platform'': Evolution and Perspectives
François Déchelle, Maurizio De Cecco, Miller Puckette, David Zicarelli
ICMC 94, Aarhus (Danemark), 1994
Copyright © Ircam - Centre Georges-Pompidou 1994
This paper describes the current evolutions and perspectives of the FTS
real-time executive as
the colonne vertébrale of the Ircam ``Real-Time Platform''
is a software oriented continuation of the ``Ircam Musical Workstation''
The most popular real-time DSP oriented software for the well-known Ircam
Musical Workstation [Lindemann91] is FTS
[Puckette91], a distributed real-time executive. FTS is a
message-oriented system, in which objects' activations are scheduled
statically for DSP computations and dynamically for control computations.
FTS has usually been used as a back end to the NeXTStep version of MAX.
2 The Open System approach
The Next Cube history proves once more that a long-lived technology must
be as independent as possible of any particular hardware or software
platform, and from vendor dependent choices.
The current evolution of FTS is in the direction of a standard open system:
FTS is becoming a hardware-independent system that can run on multiple
hardware and software platforms, and interact with user applications
in a well-defined framework.
2.1 FTS as an open server
The chosen approach is a client/server architecture, in which FTS is
the real-time server of one or more client applications connected to
it via a well-defined hardware independent protocol.
The communication itself can use different transport
layers: standard UNIX pipes, TCP connections or shared
memory in specialized hardware architectures. The chosen transport is
completely transparent with respect to the client application; the same
application can use different transport layers in different sessions,
depending on the configuration.
The kind of server used, and the platform on which the FTS server
runs, is also completely transparent to the application: the same client can
connect to a standard Ircam Musical Workstation card, an Alpha
workstation or a TMS320C40-based system in different sessions, without
any difference from the client's point of view. Of course, different
servers can include different features, like different sets of objects,
different performance levels or a different audio I/O structure.
client should not make assumptions as to the existence of a particular
server feature, but the FTS protocol includes support to publish the main
features of a server so that the client can actually know which
features are supported by a particular server.
One of the benefits of this approach is that the real-time architecture
and graphical development environments are more fully decoupled, and can
run on physically different machines connected through Ethernet or
A well-defined interface between the two components allows
specialized applications, using FTS for their DSP computations, to be
developed in programming languages other than Max. Currently,
language bindings for the FTS library are provided in C, C++, Common
Lisp and Dylan; other utilities developed include a shell command
line interface to control the FTS server and FTS applications,
and a Motif library to build specialized
application interfaces connected to FTS.
The support for multiple clients for the same server allows the use
of Max as the development environment for the FTS part, while the
final application interface is developed as an independent client
by other means.
2.2 Multiple architectures
The immediate goal is the porting of FTS to commercially available
hardware architectures, which are currently:
- PC with add-on Texas
Instruments TMS320C40 DSP boards providing the scalability
required by large musical applications,
- Unix workstations with audio devices and high processing power, such
as Silicon Graphics and DEC Alpha.
3 Evolution of FTS
A number of longer-term issues are also under consideration; a number of
case studies with FTS users both in and outside of Ircam showed
two areas of the system where improvements or added functionalities
would be worthwhile. These are automatic partitioning and compilation
of control algorithms.
Like money, computing power is never plentiful enough; most of the applications
developed at Ircam with the Musical Workstation use the
maximally expanded configuration (three cards, i.e. six i860 processors), and use the available
computing resources, CPU and memory, to their very limits.
The main consequence is that the partitioning of the different tasks on
different processors is at best a critical process; in practice,
once close to the machine limits, finding a good partitioning of the
algorithm between the processors becomes the most time-consuming
The other consequence is that working close to the limits implies that a
number of stricly architectural and platform-dependent optimization
choices are performed by the FTS programmer, and are hardcoded in the
patch itself. In the anticipated multi-platform scenario, this is clearly
a problem that will increase the cost of porting applications across
In this scenario, a system support for application partitioning is seen
as unavoidable. A development activity in this area has only just
started; the goal is to reduce the development cost of distributed FTS
applications: in the short term, we will give
more accurate metering tools to monitor the load of the different parts
of the system; in the medium term, we will develop semi-automated
utilities for partitioning of FTS programs.
The FTS DSP engine is currently highly optimized, at least at the
single DSP operation level. However, the control algorithm is
essentially interpreted. Investigation of finished works shows that
the control part is not
negligible and is sometimes the bottleneck, especially
when the system reacts to external inputs. FTS developers often use
workarounds, like extending the system audio FIFOs to cope with peak
loads (which introduces audio delays that are sometimes difficult to
handle), and splitting the control computation between different ticks
by means of delay lines.
In order to better optimize the control computation, the idea of compiling
the control part of a patch instead of interpreting it, has been considered.
Given the nature of the FTS programming language (simple data types,
simple recursive control structure), compiling it directly to a low
level byte code (or in theory to directly executable machine code),
is rather straightforward; a feasibility analysis showed that for
patches made of standard control objects (like int, float,
trigger and select),
using standard optimization techniques such as inlining,
peep-hole optimization, and a bit of data-flow analysis, we achieve
translation ratios around 1-2 machine instructions per FTS object,
giving a theoretically possible improvement in control performance
between one and two orders of magnitude over the existing system,
depending on the target compilation language.
The compiling algorithm is also compatible with an incremental
implementation, something that is essential to avoid any impact on the ease of
use of the Max programming environment.
Compiling the control algorithm also allows for a better integration of
the DSP computation (currently compiled to an intermediate language)
and the control computation, permitting a more flexible semantic of the
interaction between the two, more flexible scheduling strategies and also the
application of global
optimization to the DSP part (like elimination of sigobjects
Using a compiled approach also allows the implementation of delivery-only
versions of the FTS kernel, for use in embedded or dedicated applications.
We described in this paper the short-term and long-term evolution of the
FTS real-time executive, making it an open server and adding new features
such as partitioning tools for faster multiprocessor development and
optimization of control computation.
Eric Lindemann, François Déchelle, Michel Starkier, Bennett Smith. The Architecture of the IRCAM Musical Workstation.
Computer Music Journal, 15(3): pp. 41-50.
Miller Puckette. FTS: A Real-Time Monitor for Multiprocessor Music Synthesis.
Computer Music Journal, 15(3): pp. 58-68.
Server © IRCAM-CGP, 1996-2008 - file updated on .
Serveur © IRCAM-CGP, 1996-2008 - document mis à jour le .