threaded execution avoids stalling the CPU; and the code executed for a parameter update is "thin", entailing only
a range check, a table lookup, and an assignment operation. (AREAL offers a more elaborate mapping scheme from
an application's state variables to the raw parameters of a synthesis algorithm, discussed in section 3.2.)
3. Software Architecture
AREAL has three nested software layers: the Scheduler, the Synthesis Engine, and a C-language wrapper. The
Scheduler sends audio samples to the audio hardware, balancing low latency between control requests and audio
results, safety from audio interruptions due to other processes needing the Cpu, and scalable audio quality. The
Synthesis Engine contains a hierarchy of sound synthesis classes and a facility for handling requests from the
application and Scheduling layers. The wrapper API interfaces these two layers to the application.
The Scheduler requests audio streams from the Synthesis Engine and passes them on to the sound card. It requests samples from the Synthesis Engine to satisfy two constraints: avoiding interruptions in the audio stream
and avoiding excess latency (due to excessive precomputing of samples). Computing samples some time before
they are needed is a common strategy in real-time audio software systems: it allows samples from a particular
synthesis algorithm to be computed a block at a time, reducing per-sample overhead (function calls, etc.) and
improving use of the CPU and memory caches. This technique also reduces the likelihood of interruptions in the
audio output on multitasking computers. The operating system may pre-emptively assign the CPU to internal tasks;
if it does not provide the process which is computing audio data a consistently steady share of processor time, this
audio process may become starved of CPU time and cause an audio interruption. Very short buffer times give low
latency but often result in audio interruptions from actions as simple as moving the mouse. Longer buffer durations offer correspondingly greater resistance to audio interruptions but at the expense of possibly unacceptable
latency. By default, AREAL uses a conservative 150 msec buffer, adequate for a 100 MHz Pentium running Windows 95. A computer running Windows NT or with a faster processor can use a shorter buffer, but if the computer
is performing other tasks a near-ideal latency of under 5 msec remains unrealistic.
The Synthesis Engine contains a hierarchy of sound synthesis classes and a facility for handling messages
from the Wrapper and Scheduling layers. Upon initialization, a list of sound objects is instantiated. When the
Scheduler requests samples (through a callback function), the Synthesis Engine obtains buffers of samples from
each synthesis object and sums them into the buffer that has been passed from the Scheduler.
Each class in AREAL's sound synthesis class library specifies a particular synthesis algorithm and defines a
standard class interface. We envision an "open" sound synthesis class hierarchy, allowing extensions of current
synthesis algorithms and addition of entirely new ones based on particular rendering and optimization requirements. The library is currently extensible at the source-code level. In a future version, however, we anticipate that
this extensibility will be realized through implementation as an ActiveX container or through the Component
Object Model paradigm. These Microsoft standards allow different applications to exchange information and for
one application to embed itself into the other, in effect becoming a component of it. In this way, sound synthesis
libraries could be "dropped into" AREAL.
The C-language wrapper acts as interface between these internals and an application. The interface exported
by the AREAL DLL is purely a set of C functions. This simplifies the interface and lets applications written in
languages other than C++ (notably Java) to use the AREAL DLL. The functions in this interface instantiate and
control synthesis objects and also define data-to-renderer mappings.
3.1 Scalable Audio Quality
AREAL avoids sample underflow in a novel way by gracefully degrading audio quality. A facility called the
OctaneMeister monitors the computer's CPU load. As this load nears 100%, the OctaneMeister tells each instantiated synthesis object to lower its computational "octane" requirement. Conversely, when the CPU load is low,
synthesis objects gradually increase their level of octane use. How this is done is specific to each synthesis class.
Moreover, synthesis objects are ranked in order of complexity: those whose performance would be most seriously
compromised by lowering their octane use are placed at the bottom of the list.
Instead of holding synthesis parameters constant for each buffer of computation, AREAL synthesis objects can
use a dynamically variable k-rate as described in [Freed 92]. One way synthesis algorithms can reduce CPU usage
is by reducing the k-rates of various synthesis parameters, thereby reducing the frequency of recalculation of these
