PERFORMING REAL-TIME SCHEDULING IN AN

INTERACTIVE AUDIO-STREAMING APPLICATION

Julien Cordry, Nicolas Bouillot, Samia Bouzefrane

Laboratoire CEDRIC, Conservatoire National des Arts et Métiers, 292, rue Saint Martin, 75141 , Paris, France

Keywords: multimedia application, real-time scheduling, real-time system, distributed system.

Abstract: The CEDRIC and the IRCAM conduct since 2002 a project entitled "distributed orchestra" which proposes to

coordinate on a network the actors of a musical orchestra (musicians, sound engineer, listeners) in order to

produce a live concert. At each site (musician), mainly two components are active: the sound engine (FTS)

and an auto-synchronisation module (nJam), two modules which must treat audio streams in real time and

exchange them via the network. These components were first made to run under the Linux environment,

where the available schedulers are imposed. For this purpose, we choose to use Bossa, a platform grafted on

the Linux kernel in order to integrate new real-time schedulers.

1 INTRODUCTION

The distributed virtual orchestra is the result of a co-

operation between the research laboratories of the

IRCAM and the CEDRIC-CNAM

(Bouillot N., 2003)

(Locher H.-N. et al., 2003). The aim of this project is to

provide means to connect musicians that would play

in real time via Internet. The current version runs

over a multicast network. The musicians

communicate via PCM audio streams, a constraint

allowing a high quality hearing of the different audio

streams. Each musician broadcasts towards the other

musicians the music which he/she plays and hears the

music that he/she has just played after a constant

latency. Our purpose is to schedule the different

processes of each site, particularly those generated by

the sound device and the self-synchronization by

using a suitable real-time scheduling technique in

order to improve the global performances of the

application. We have chosen to use Bossa, an event-

based framework for process-scheduler development.

This choice is motivated by the following points:

- to use a "Bossa" scheduling for “Linux native”

appl

ications, both Linux and application must be

modified. However, a minimum of insertion of code

(three lines of code by process to attach it to a

specific scheduler) are required in an application

code to benefit from BOSSA schedulers. Linux is

automatically modified by Bossa: a set of rewriting

rules are applied to the sources of the Linux core.

This way allows us to test and configure easily new

schedulers in an environment (Linux) where many

applications are available. One could have used real-

time Linux such as RTAI

but this requires the

complete rewriting of the application considering the

particular structure of the real-time tasks and the

particular libraries to include.

- We will be able to use a real-time scheduler for

e management of the processes of our multi-media

application, rather than those of Linux

(SCHED_FIFO or SCHED_RR).

The paper is organised as follows. In section 2,

we describe the characteristics of our multi-media

application, the distributed virtual orchestra. In

section 3, we present the Bossa platform and we

show how it can integrate new scheduling policies. In

section 4, we determine the application processes

which need to be scheduled in real time, by defining

a scheduler hierarchy. Before concluding in section

6, section 5 presents our experiments, where we

show that BOSSA helps our application to meet the

timing constraints.

2 THE DISTRIBUTED VIRTUAL

ORCHESTRA

The free-software team of IRCAM and the

multimedia research team from CNAM-CEDRIC

conduct a project since 2002 named the "distributed

Real-Time Application Interfaces, developed in

Dipartimento di Ingeniera Aerospaziale, Politecnico

di Milano of Prof Paola Mantegazza

(http://www.aero.polimi.it/~rtai/applications /)

140

Cordry J., Bouillot N. and Bouzefrane S. (2005).

PERFORMING REAL-TIME SCHEDULING IN AN INTERACTIVE AUDIO-STREAMING APPLICATION.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 140-147

DOI: 10.5220/0002535501400147

 SciTePress

virtual orchestra". The aim of this project is to

provide means for musicians to play across the

Internet in real time (see Figure 1)

(Bouillot N., 2003)

(Locher H.-N. et al., 2003).

The application constraints are as follows:

- the musicians are physically separated but must

play virtually "together" in real time.

- the sound engineer must be able to adjust in real

time the audio parameters of the various sound

sources (e.g., to add reverberation effects, etc).

- the public must be able to virtually attend the

concert, either at home by a standard mechanism of

audio/video streaming, or in a room with a dedicated

installation.

In this paper, we are interested in the part

concerning the musicians only, since it is a critical

part in term of interactivity. Our application uses

jMax, a visual programming environment dedicated

to interactive real-time music and multimedia

applications

(Déchelle F., 2000). jMax has been

developed by the IRCAM. It is composed of two

parts: FTS for "faster than sound", a real-time sound

processing engine and a graphical user interface

which allows to add, remove or connect components

that exchange audio samples or discrete values. Some

examples of components available in jMax are the

inputs/outputs of the sound device, the arithmetic

operations and the digital audio filters. Since jMax is

often used to make audio synthesis, it has an

interface with the operating system, ALSA (for

Advanced Linux Sound Architecture) for Linux.

As we are close to virtual-reality conditions, the

sound quality, the feeling of presence, as well as

synchronism among musicians are crucial conditions.

For this reason, the technology developed for the

distributed concert uses a non compressed sound

(PCM samples at 44100Hz 16 bit, corresponding to

the quality of an audio CD). Additionally we use the

multicast with the RTP protocol

(Schulzrinne et al.,

1998)

for the communication among musicians. For

the feeling of presence, during our experiments, a

videoconference software allowed remote

visualisation among the musicians.

Usually, the musical interaction (all musicians in

the same room) is enabled thanks to a common

perception among musicians: the sound and the

visual events are perceived instantaneously,

simultaneously and with a sound quality limited by

the capacities of the human ears and eyes.

During networked performances, we can provide

the better quality for the sound, but we cannot

provide instantaneity. In fact, we estimate that 20ms

is the threshold above which the human ear perceives

the shifts. For this reason, we ensure a global

simultaneity among musicians thanks to a

synchronization mechanism described in

(Bouillot N.,

2003)

(Nicolas Bouillot N. et Gressier-Soudan E., 2004)

and implemented inside nJam (for network Jam), a

pluggin of jMax. This synchronization ensures that

the return of the overall mix of the music is identical

for all the musicians. nJam computes the diffusion of

the sound through multicast with RTP, the

synchronization of the audio streams, and the shift

between the musicians. Thus, the musicians specify a

tempo, as well as the shift in musical units (a beat, an

eighth note, a sixteenth note, etc). This parameter

enables them to have a shifted feedback, which is

synchronized and matches the beats of the music they

are playing on their instrument.

We can extract some constraints for the operating

system and the network: each instance of nJam will

send on the network only one audio stream and will

receive N from them (if N sites are involved). Then,

FTS manages at least one component corresponding

to an input (microphone or instrument) and one

component for each output of the sound device.

Within the RTP protocol, the isochronism of the

audio data is ensured by a time-stamping that

corresponds to the number of audio samples.

Additionally, each site is controlled by its own clock,

that came from the local sound device. At each site-

clock tick, a sample of 16 bits is produced and a

sample coming from each source is consumed. Thus,

the constraints of end-to-end temporal delivery are

crucial, either for the network part or for the system

part FTS/ALSA.

In this paper, we focus on the schedule of various

application components by using a real-time

scheduling technique.

3 BOSSA

The distributed virtual orchestra is an application

written in C whose execution environment is the

Linux system. From a system point of view, this

application is confronted with the resource sharing,

in particular in terms of access to the processor and

to the peripherals (network device and sound

device). However, a guaranteed periodic access to

these resources is necessary. In this context, the use

of a real-time Linux system (such as RT-Linux

RTAI) would enable us to try out scheduling policies

not available on the traditional Linux system.

Nevertheless, to profit from these policies, the target

application must respect the structure of the real-

time tasks and include the particular function calls of

the library of real-time Linux. To avoid modifying

the source code that deals with the logic of the

application, we choose to use rather Bossa. Indeed,

to our knowledge, it is the only platform which can

http://www.fsmlabs.com

PERFORMING REAL-TIME SCHEDULING IN AN INTERACTIVE AUDIO-STREAMING APPLICATION

141

integrate real-time schedulers into the Linux core,

thus allowing Linux processes to be scheduled

according to a scheduling policy integrated in Bossa.

The only modification to perform on the source code

of the process is the insertion of a function call used

to attach the process to the selected scheduler.

Before presenting the Bossa

platform, we

describe the Bossa DSL (domain-specific language)

used to implement new scheduling policies.

3.1 The Bossa DSL

The technique used by Bossa to integrate new

scheduling policies in an existing operating system is

the use of a dedicated language (DSL: Domain

Specific Language). A DSL is a programming

language providing high-level abstractions

appropriate to a given domain and permitting

scheduling-specific verifications and optimizations.

Each scheduling policy in Bossa is implemented

as a collection of event handlers that are written in

Bossa DSL and translated into a C file by a dedicated

compiler. A Bossa scheduling policy declares: (i) a

collection of scheduling-related structures to be used

by the policy, (ii) a set of event handlers, and (iii) a

set of interface functions, allowing users to interact

with the scheduler.

Table 1 shows some of the declarations made by the

Bossa implementation of the Linux 2.2 policy. The

process declaration lists the policy-specific

attributes associated with each process. As reflected

by the policy field, the Linux 2.2 scheduling

policy manages FIFO and round-robin real-time

processes, as well as non real-time processes. The

other fields of the process structure are used to

determine the current priority of the associated

process. Finally, the ordering_criteria

declaration specifies how the relative priority of

processes is computed. Table 1 shows also examples

of event handlers of the Linux2.2 policy. For

example, the event handler block. * moves the

target process to the blocked process whereas the

event handler unblock. * moves the target

process from the blocked queue to the ready queue.

3.2 From the Linux kernel to Bossa

The developers of Bossa examined the problem of

operating system (OS) evolution in the context of

adding support for scheduler development into the

Linux OS kernel. The goal of Bossa is to simplify

the design of a kernel-level process scheduler so that

an application programmer can develop specific

policies without expert-level OS knowledge

(Julia L.

http://www.emn.fr/x-info/bossa

Lawall et al., 2004) (Barretto L. P. et al. 2002). A Bossa

scheduling policy is implemented as a module that

receives information about process state changes

from the kernel via event notifications and uses this

information to make scheduling decisions.

Table 1: Declarations of the Linux 2.2 policy

Declarations Event Handlers

type policy_t =

enum {SCHED

FIFO,

SCHED_RR, SCHED_OTHER}

process = {

policy_t policy;

int rt_priority;

time priority;

time ticks;

system struct ctx mm;

}

On block.* {

e.target =>

bocked;

}

On unblock.*

{

if (e.target

in blocked) {

e.target =>

ready;

}

ordering_criteria = {

highest rt_priority,

highest ticks,

highest

((mm==old_running.mm)?

1:0)}

Preparing a kernel for use with Bossa requires

inserting these event notifications at scheduling

points throughout the kernel. The evolution of the

Linux kernel to support Bossa is rather complex, for

various reasons. First, Bossa would like to be used

across the many sub-series of Linux releases, which

do not contain new algorithms. A solution based on

patches is not sufficient because the line numbers of

the scheduling points as well as the code surrounding

these points can differ across releases. Second, some

of the changes required to support Bossa depend on

control-flow properties. Detecting such properties by

hand is error-prone even when considering a single

version of Linux. Finally, making any changes by

hand across multiple files of a large piece of software

(Linux currently amounts to over 100MB of source

code), is tedious and error-prone. Hence, the

rewriting principle has been used to implement a

crosscutting functionality that contains a collection of

code fragments and a formal description of the points

at which these fragments should be inserted into the

target application. This functionality uses temporal

logic to precisely describe code insertion points and

thus resolve the context-sensitivity issue.

An example of a rewrite rule is the following as it

is described in

(Aberg R. A. et al., 2003):

n:(call try_to_wake_up))

=>Rewrite(n,

bossa_unblock_process(args))

ICEIS 2005 - HUMAN-COMPUTER INTERACTION

142

This rule matches any call to the function

try_to_wake_up. A node matching this pattern is

given the name n. The use of Rewrite indicates

that the call to try_to_wake_up is replaced by a

call to bossa_unblock_process. The function

wake_up_process shown below illustrates the

effect of applying this rule.

wake_up_process(struct task_struct * p)

{

#ifdef CONFIG_BOSSA

return bossa_unblock_process

(WAKE_UP_PROCESS, p, 0);

#else

return try_to_wake_up(p, 0);

#endif

}

The Linux kernel is rewritten using over forty

logical rules of a rather great complexity

implemented in Ocaml and Perl via CIL (C

Intermediate Language). Even with these methods

which are supposed to guarantee a minimum of

reliability, the error is always possible. Thus, when

using Bossa with the distributed virtual orchestra, we

could note the failure of a rewriting rule.

3.3 Bossa: a hierarchy of schedulers

A scheduler is a complex application since that it

requires understanding the operation of multiple low-

level kernel mechanisms. Ideally, to be able to

implement new scheduling policies, the scheduler

and the rest of the kernel must be completely distinct

but perfectly interfaced.

Bossa proposes a specific abstraction level to

scheduling domain. Instead of calling directly the

functions of the scheduler (typically schedule ()),

the drivers call a system of events. Indeed, the Bossa

framework replaces scheduling actions in the kernel,

such as the modifying of a process state or the

electing of a new process, by Bossa event

notifications. Event notifications are processed by

Bossa run-time system (RTS) (see Figure 2) which

invokes the appropriate handler defined by the

scheduling policy.

To resolve the problem of coexistence of real-

time and non real-time programs, Bossa introduced

the concept of hierarchy of schedulers. A process

scheduler is a traditional scheduler that manages the

processes in order to allocate to them a processor

time. A virtual scheduler is a scheduler that controls

other schedulers. Thus, one can create a virtual

scheduler with child schedulers to which it can give

control according to well defined criteria (for

example, priority) or according to a proportion (for

example the virtual scheduler will give control once

on three to the child scheduler number 1 and twice

out of three to the child scheduler number 2). The

system scheduler will thus have a tree form where

nodes are virtual schedulers and leaves are process

schedulers. The main difference between a process

scheduler and a virtual scheduler is the handling of

events. The Bossa run-time system sends the event to

the first scheduler in the hierarchy. After receiving

the event, a virtual scheduler forwards the event to

the appropriate child scheduler and then updates the

child scheduler state according to the result of the

event treatment.

4 REAL-TIME SCHEDULING OF

THE DISTRIBUTED

ORCHESTRA

Many real-time scheduling algorithms are described

in the literature

(Cottet F et al., 2002) nevertheless they

are not implemented on usual (non real-time)

operating systems. We have chosen Bossa because

our multimedia application will continue running

under Linux while using a real-time scheduling

strategy for the processes.

In the remainder of this section, we will

investigate the real-time processes of the distributed

orchestra that must be scheduled by using a real-time

scheduling policy. For this purpose, we will be

interested in the FTS/jMax and nJam modules that

constitute the heart of our application.

4.1 Analyzing FTS and nJam

processes

As explained in section 2, at each site FTS, the audio

engine, manages the jMax components like the audio

inputs/outputs or nJam (the pluggin of jMax). During

the initialization of FTS (when starting jMax),

modules (like ALSA under Linux ) will be loaded.

Then, the user can define, connect and set parameters

of the components via a graphical interface. The FTS

engine has a loop structure(see the following code):

the functions associated to the components are

executed one by one (with a beat driven by the sound

card). Indeed, the function

fts_sched_do_select returns in

main_sched the list of the functions to be

executed.

void fts_sched_run(void)

{

while(main_sched.status! =

sched_halted)

PERFORMING REAL-TIME SCHEDULING IN AN INTERACTIVE AUDIO-STREAMING APPLICATION

143

fts_sched_do_select(&main_sched);

}

FTS starts by analyzing the output of the

graphical interface to deduce a set of dependences

between FTS components. The execution of the

functions associated to the components will allow

audio-data exchange between components and a

possible output over the sound device. This loop is

critical since each function registered in FTS engine

corresponds to a set of samples which must be

available to the next cycle. During our experiments,

the cycles were equivalent to 64 samples each,

corresponding to a duration of 64/44100 seconds, i.e.,

1.45 ms.

In addition to FTS, the nJam patch synchronize

musicians to provide the perceptive consistency

(Nicolas Bouillot N. et Gressier-Soudan E., 2004).

Additionally, it keeps the isochronism from end to

end by playing null sample when data come late

(RTP is build on top of UDP). In this way, nJam

needs periodical accesses to the sound card and the

network interface nJam starts mainly a thread which

loops on the reception and the sending of RTP

packets until the end of connections. It is the

greediest operation from the resources point of view.

4.2 The distributed orchestra under

Bossa

To run the distributed orchestra under Bossa, we

define a scheduler hierarchy. The development team

of Bossa has already worked on multi-media

applications

(Consel C. et Marlet R., 1998). Indeed, they

developed a version of mplayer that uses the EDF

technique. This version requires to define the

attachment of the application to the scheduler with a

period and an execution time expressed in jiffies

(CPU clock ticks). We define a tree structure with

one level so that the root which corresponds to a

virtual scheduler is composed of two child process

schedulers: one process scheduler corresponds to the

EDF version of mplayer and the other one is a

traditional Linux process scheduler. The virtual

scheduler is a fixed-priority based scheduler, in other

words it handles two child schedulers having static

priorities. In our case, the priorities are associated to

the process schedulers so as to favour systematically

EDF over a Linux scheduler. The following

commands allow the creation of the schedulers

hierarchy of Figure 3.

panoramix:/home/cordry # modprobe EDFu

panoramix:/home/cordry # modprobe

Fixed_priority

panoramix:/home/cordry # /bin/manager

Available schedulers:

0. Linux (PS, root, default)

1. EDFu (PS, not loaded, not default)

2. Fixed_priority (VS, not loaded,

default)

Default path:

Linux

Command: (the scheduler number uses)

C <P> <C> connect relative scheduler P

to child scheduler C

D <S> disconnect scheduler S

L list available schedulers

H print this help finely

Q quit

> C 2 0

int importance_10: 5

> C 2 1

int importance_10: 7

> L

Available schedulers:

0. Linux (PS, loaded, default)

1. EDFu (PS, loaded, not default)

2. Fixed_priority (VS, root, default)

Default path:

Fixed_priority - > Linux

> Q

All the processes will be executed by default

under Linux, except for the principal loop of FTS

(which makes audio computation) and the nJam

thread (in charge of the emissions and receptions of

RTP packets) which will be scheduled in real time.

Any process which must be scheduled under

Bossa, must be attached to a scheduling policy. In the

context of our application, FTS loop will be attached

to EDF scheduler while specifying the worst case

execution time of the loop and its deadline that is

equal to its period.

To compute the execution time of FTS loop, it is

necessary to evaluate the execution time of the

various functions called. These functions associated

with the components prepare 64 samples at each

clock tick of the sound device, that is, a cycle which

takes 64/44100=1.45 ms. Greater is the number of

components, greater is the number of associated

functions, which increases the execution time of FTS

loop. In our experiments, according to the number of

components defined, we limited the execution time

of FTS loop to 4 jiffies (CPU clock ticks, on a

modern hardware a jiffie approximates 10ms) and

fixed its period to 5 jiffies.

The following code shows the modifications that

were have carried out on FTS loop in order to attach

it to EDF scheduler.

ICEIS 2005 - HUMAN-COMPUTER INTERACTION

144

/* we include the definitions of EDFu

# include " user_stub_EDFu.h "

void FTS_sched_run(void)

{

int period = 5;

int wcet = 4;

/* we attach the current process to the

EDFu scheduler * /

if (EDFu_attach(0,period,wcet) < 0)

FTS_post("Cannot attach (%s)\n",

strerror( errno));

while(main_sched.status! =

sched_halted)

FTS_sched_do_select(&main_sched);

/* we loop on the list of functions

called by FTS until the end */

}

Similarly, we attached the nJam thread to the

EDF scheduler by assigning to the thread a period

equal to 10 jiffies and a worst case execution time of

1 jiffie. The following code shows this attachment.

void start_routine(nJam_t * this)

{

struct timeval timeout;

pid_t my_pid;

int wcet = 1;

int period = 10;

my_pid = getpid();

if (EDFu_attach(0, period, wcet) < 0)

fts_post("Cannot attach %u (%s)

\n",my_pid,strerror( errno));

pthread_exit(0);

}

5 PERFORMANCES EVALUATION

We have run the distributed orchestra application by

using sound automates that generate a 16 bit PCM

audio signal at a frequency of 44100 Hz (one

automate on each site). The machine called "breton"

has an Intel processor of 3 GHz with a memory of 1

GB and uses Linux as operating system (kernel

2.6.5). The machine "panoramix " has an Intel

processor of 350 MHz with a memory of 256 MB

and uses Linux with two kernels (Bossa and kernel

2.4.21). The curves we present correspond to the

quantity of data stored in the buffers of nJam, each

buffer corresponds to a musical source. These data

are regularly consumed by FTS in order to feed the

sound device. Since the production of audio samples

as their consumption take place at the same rate

theoretically (if we consider that the clocks of the

sound cards do not derive), the quantity of data

should be constant, modulo the jitter of the network.

The measurements are made from the first

communication between the machines, showing

abrupt increasing due to the adjustment of latencies

to synchronize audio streams.

Figure 4 shows the ideal situation for the machine

panoramix (which runs under Bossa), i.e. when the

system is not overloaded. In this case, the

producer/consumer relation of the audio streams

coming from panoramix and breton is correctly

preserved (the curves are constant starting from the

33th second).

Figure 5 shows the case where the machine

panoramix runs with a Linux system loaded thanks

to a script and started at the 29th second on

panoramix. From this moment, the audio samples are

not heard any more at the output of the sound device,

causing an imbalance in the producer/consumer

relation of nJam. The curve of figure 5 shows the

nJam buffer size of panoramix machine. We can see

that the data coming from breton are not consumed

since their quantity increases. However, the local

stream remains constant, letting us assume that the

data are not sent. This assumption is confirmed by

the curve of figure 6, because the machine breton

stops abruptly the reception of data from panoramix

at the 50th second. We thus see clearly thanks to

figure 5 that processor loads blocks completely the

access to the sound device (FTS process) as well as

the sending and the reception of the data on the

network (thread nJam) .

We made the same load test with panoramix

while running under Bossa. Process FTS as well as

the thread nJam being scheduled with an EDF policy.

In this case, in spite of the load, we can see on figure

7 that the machine panoramix is not disturbed by the

load script, neither in relation with the network, nor

regarding to the sound-device access. It shows that

nJam meet its timing constraint, instead of an heavily

loaded system.

6 CONCLUSION

The project on the distributed virtual orchestra aims

to provide means to allow to remote musicians to

play music via Internet. In this paper, we provide

some execution guaranties, which help the

application to satisfy the temporal requirement, both

for the local device and for the network access.

In addition to FTS/jMax module, N. Bouillot

proposed an audio-stream synchronization algorithm

PERFORMING REAL-TIME SCHEDULING IN AN INTERACTIVE AUDIO-STREAMING APPLICATION

145

to provide synchronism among the musicians. This

algorithm is implemented as a jMax pluggin. We

wanted to show here how we proceed to schedule the

various processes generated by these components by

using a real-time scheduling technique in order to

handle the temporal constraints of the application.

We chose to use Bossa, an event-based platform

which integrates easily new scheduling policies

without changing the operating system. We used the

concept of scheduler hierarchy defined in Bossa to

schedule the real-time processes of our application

according to an EDF-based technique more

appropriate to the multi-media domain. Non real-time

processes are handled by a traditional scheduler of

Linux.

Finally, the experiments carried out show that we

can test and configure specific schedulers in a widely

deployed desktop environment (Linux). Thus, we

argue that BOSSA allows us to test new schedulers

easily with multimedia applications and with a small

cost. However, the Linux kernel must be replaced by

the kernel modified by the BOSSA rewriting rules.

This modifications performed on Linux can be

performed only by specialists.

Several search directions can be explored as a

perspective to this work. Nevertheless the direction

which seems to be essential to pursue this work

concerns

o first, a precise study of the parameters relating to

the quality of service of the network which could

influence the temporal characteristics of the real-

time processes of the distributed orchestra and

o second, the configuration of the scheduler. We

have seen that the scheduler is configured with

Jiffies. However, our constraints are expressed in

time units which depend on the sound-device

clock. Thus, we plan to modify Bossa to use

system calls, as the access to the sound device,

inside the scheduler configuration

ACKNOWLEDGMENTS

We would thank Mr Gilles Muller, Professor at Ecole

des Mines de Nantes (France) and a Bossa-team

member, and Mr Jean-Ferdinand Susini, Associate-

Professor at CNAM (Paris), for their relevant

remarks that help us to improve the content of this

paper.

REFERENCES

Aberg R. A., Lawall J.L., Südholt M., Muller G. And Le

Meur A.-F., "On the automatic evolution of an OS

kernel using temporal logic and AOP", Automated

Software Engineering, 2003.

Baretto L. P. et Muller G., "Bossa: a language-based

approach to the design of real-time schedulers", In 10th

International Conference on Real-Time Systems

(RTS'2002), pages 19-31, Paris, France,march 2002.

Bouillot N., "Un algorithme d'auto synchronisation

distribuée de flux audio dans le concert virtuel réparti",

RenPar'15, CFSE'2003, SympAAA'2003, pp.441-452,

France, oct. 2003.

Nicolas Bouillot N. et Gressier-Soudan E.,"Consistency

models for Distributed Interactive Multimedia

Applications". A paraître dans Operating Systems

Review. Volume 38, issue 3. Octobre 2004.

Consel C. et Marlet R., "Architecturing software using a

methodology for language development", Proc. of the

10th Intern. Symp. On Programming Languages,

Implementations, Logics and Programs, Pise, Italy, pp.

170-194, 1998.

Cottet F., Delacroix J., Kaiser C. et Mammeri Z.,

"Scheduling in Real-Time Systems", Wiley Ed., 261

pages, 2002.

Déchelle F., "jmax: un environnement pour la réalisation

d'applications musicales temps réel sous Linux", Actes

des journées d'Informatique Musicale, 2000.

Julia L. Lawall, Gilles Muller, Hervé Duchesne, "language

design for implementing process scheduling

hierarchies", Invited application paper, in Proc. of the

ACM/SIGPLAN Workshop Partial Evaluation and

Semantics-Based Program Manipulation Proceedings

of the 2004 ACM SIGPLAN symposium on Partial

evaluation and semantics-based program manipulation,

pages 80-91, ISBN:1-58113-835-0, Italy, August 24-

25, 2004.

Julia Lawall, Gilles Muller, Anne-Francoise Le Meur, " On

the design of a domain-specific language for OS

process-scheduling extensions", in Proc. of the Third

International Conference on Generative Programming

and Component Engineering (GPCE'04), Vancouver,

October 24-28, 2004.

Locher H.-N., Bouillot N. Becquet E., Déchelle F. &

Gressier-Soudan E.,"Monitoring the Distributed Virtual

Orchestra with a CORBA based Object Oriented Real-

Time Data Distribution Service", International

Symposium on Distributed Object Application, nov.

2003. Catagne, Italy.

Schulzrinne, Casner, Frederick and Jacobson. RTP: A

Transport Protocol for Real-Time Applications. RFC

1889. 1998.

ICEIS 2005 - HUMAN-COMPUTER INTERACTION

146

Figure 1: The distributed virtual orchestra

Figure 2: Bossa architecture

Figure 3: A scheduler hierarchy

Figure 4: The behaviour of panoramix using Bossa and

breton using Linux when the system is not loaded (from

panoramix point of view)

Figure 5: The buffers sizes of panoramix and breton when

they run under Linux with a loaded system(from panoramix

point of view)

Figure 6: Buffers size of panoramix and breton running

under Linux with a loaded system (from breton point of

view)

Figure 7 Buffers size of panoramix running under Bossa

with a loaded system

PERFORMING REAL-TIME SCHEDULING IN AN INTERACTIVE AUDIO-STREAMING APPLICATION

147