Network Latency Adaptive Tempo
in the Public Sound Objects System

Álvaro Barbosa
† ‡

†
Music Technology Group
Pompeu Fabra University
Calle Ocata 1, 08003
Barcelona, Spain
+34 93 542 21 04
abarbosa@iua.upf.es
Jorge Cardoso
‡
Research Center for Science and
Technology of the Arts (CITAR)
Portuguese Catholic University
Rua Diogo Botelho 1327,
4169-005 Porto, Portugal
+351 22 616 62 91
jccardoso@porto.ucp.pt
Gunter Geiger
†
Music Technology Group
Pompeu Fabra University
Calle Ocata 1, 08003
Barcelona, Spain
+34 93 542 21 04
ggeiger@iua.upf.es

ABSTRACT
In recent years Computer Network-Music has increasingly
captured the attention of the Computer Music Community. With
the advent of Internet communication, geographical displacement
amongst the participants of a computer mediated music
performance achieved world wide extension. However, when
established over long distance networks, this form of musical
communication has a fundamental problem: network latency (or
net-delay) is an impediment for real-time collaboration. From a
recent study, carried out by the authors, a relation between
network latency tolerance and Music Tempo was established.
This result emerged from an experiment, in which simulated
network latency conditions were applied to the performance of
different musicians playing jazz standard tunes.
The Public Sound Objects (PSOs) project is web-based shared
musical space, which has been an experimental framework to
implement and test different approaches for on-line music
communication. This paper describe features implemented in the
latest version of the PSOs system, including the notion of a
network-music instrument incorporating latency as a software
function, by dynamically adapting its tempo to the
communication delay measured in real-time.
Keywords
Network Music Instruments; Latency in Real-Time Performance;
Interface-Decoupled Electronic Musical Instruments; Behavioral
Driven Interfaces; Collaborative Remote Music Performance;
1. INTRODUCTION
Research work in the Network-Music field has recently been
published in surveys from Álvaro Barbosa in 2003 [1], Gill
Weinberg in 2002 [2] and Dante Tanzi in 2001 [3], which
describe and categorize several different systems, following
diverse architectures and topologies.

These systems make use of a long distance communication media
with specific characteristics which must be dealt with. Network
latency and Jitter represent the most distinguishable difference
from presential music collaboration paradigms, since music
performance is traditionally bounded to the notion of real-time
synchronism between instruments and performers.
It can be demonstrated that at a globe level there are physical
limitations in current network technology, which will always
introduce higher latency than the minimum acceptable values for
real-time acoustic collaboration [1] [4] [5].
A particular approach to face such scenario is accepting net-delay
as a natural element when creating music over the internet. The
thought that net-delay is the particular acoustics of Internet and
that composers should try to find a musical language that works
on this time axis is clearly expressed by the experimental artist
Atau Tanaka in [6]. The concept of an Internet acoustic space and
the influence of network conditions in acoustic communication
has also been addressed by Chris Chafe from the SoundWIRE
group, at Stanford University’s Center for Research in Music and
Acoustics (CCRMA) [7].
2. TEMPO AND LATENCY
A number of experiments have been carried out with the purpose
of determining the maximum amount of communication latency
which can be tolerated between musicians in order to keep up
with a synchronous performance.
Some of the most significant results regarding the effects of time
delay on ensemble accuracy were published in 2004 by Chris
Chafe and Michael Gurevish [8]. From the experiment conducted
at CCRMA it is clear that by increasing the communication delay
between pairs of subjects trying to synchronize a clapping steady
rhythm, the subjects tend to slow down the performance rhythm
(Tempo).
Similarly, an experiment carried out by the authors in June 2004
at the Sound and Image Department from the Portuguese Catholic
University aimed, amongst other goals, to study the relationship
between Tempo and Latency.
In the experiment, simulated network latency conditions were
applied to the performance of four different musicians playing
jazz standard tunes with four different instruments (Bass,
Percussion, Piano and Guitar).
Permission to make digital or hard copies of all or part of this work
for personal or classroom use is granted without fee provided that
copies are not made or distributed for profit or commercial
advantage and that copies bear this notice and the full citation on the
first page. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee.
NIME'05, May 26-28, 2005, Vancouver, BC, Canada.
Copyright remains with the author(s).

In a studio setup, musicians would listen to the feed-back from
their own instruments trough headphones with delay. Their
performance was synchronized with a metronome over several
takes with different tempos (Beats Per Minute – BPMs). For each
take the feed-back delay was increased until the musician wasn’t
able to keep up a synchronous performance.
80 100 120 140 160 180 200 220
50
100
150
200
250
Tempo (BPMs)
L
a
t
e
n
c
y

(
m
s
)
Musician #1 - Bass
Musician #2 - Percussion
Musician #3 - Piano
Musician #4 - Guitar

Figure 1. Self-Test for latency tolerance in individual
performance of 4 different musicians
The Graphic on Figure 1 shows that, regardless of the
instrumental skills or the music instrument, all musicians were
able to tolerate more feed-back delay for slower Tempos,
therefore, it is clear that there is an inverse relationship between
Tempo an Latency. After obtaining these results the authors
proceeded to implement this concept on the Public Sound Objects
(PSOs) system, aiming to achieve a network-music instrument
which incorporates latency as a software feature, by dynamically
adapting its tempo to the communication delay measured in real-
time.
3. THE PUBLIC SOUND OBJECTS
The Public Sound Objects (PSOs) project is web-based
Collaborative Virtual Environment focused on music
performance, developed at the Music Technology Group of the
Pompeu Fabra University. This project has been an experimental
framework to implement and test different approaches for on-line
music communication. A preliminary specification of the system
was published in [9], and the first prototype was implemented in
December 2002
1
.
The overall system architecture was designed along the following
key aspects: (a) It is based on a Centralized Server Topology
supporting multiple users connected simultaneously and
communicating amongst themselves through sound; (b) It is a

1
The PSOs experimental system is publicly available on-line
from the address: http://www.iua.upf.es/~abarbosa/
permanent public event available both to a “real world” and on-
line virtual audience.
In this system the raw materials provided to the users for
manipulation during a performance are Sound Objects, according
to Pierre Schaeffer’s definition “any sound phenomenon or event
perceived as a coherent whole (…) regardless of its source or
meaning” [10].
These Sound Objects are triggered at the server-side real-time
sound synthesizer according to the user’s action. Since the Feed-
Back from other user’s performance is strictly auditory, the
characteristic which makes a Sound Object distinguishable from
the overall soundscape is the key element that permits the
awareness of the individual action of a user over his performance.
4. THE PSOs ARCHITECTURE
The PSOs system is composed by the PSOs Server and by
multiple PSOs Clients. Clients handle a visual interactive
interface and the server handles all computation regarding the
sound synthesis and transformation..
PSOs
SERVER
(...)
PSOs CLIENTS
STREAMING
AUDIO SERVER
HTTP-SERVER
INTERACTION
SERVER
LOCAL VISUAL
REPRESENTATION
ENGINE
Public Installation Site
INTERNET
Global Audio Performance
(Continuous Streaming Connection)
Performance Commands
(Discrete Connection triggered by client events)
SOUND
OBJECTS
DATA-BASE
WEB BROWSER
Streaming Audio Client
Controller Interface
WEB BROWSER
Streaming Audio Client
Controller Interface
WEB BROWSER
Streaming Audio Client
Controller Interface
Apache + Custom Developed Servlet
ICECAST Streaming Server
Pure-Data
Pure-Data
Pure-Data + GEM

Figure 2. The PSOs System Architecture
Clients communicate with the server through HTTP by sending
and receiving packets of data. At the server packets are received
by a Web application that reroutes them to the Interaction Server
– a module of the PSOs Server that manages clients, instruments
and the events generated by the PSOs Client. Depending upon the
type of data packet received, a sound can be generated by the
Synthesis and Transformation Engine and streamed back to the
client by the Streaming Audio Server, or the visual representation
of the client can be updated at the installation site by the Local
Visual Representation Engine, or both.
Server and Clients are composed by different modules: