The Scheduler handles the passage of samples to the sound card. It does this by iteratively filling buffers with samples as these are computed within the Synthesis Engine and inserting these into the sound card's queue. It maintains as low a latency as possible while providing sufficient safety from audio interruptions due to other processes needing the CPU. When the Scheduler needs more samples, it executes a callback against the Synthesis Engine.
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 execution of its callback procedure), the Synthesis Engine obtains buffers of samples from each synthesis object and sums them into the buffer that has been passed from the Scheduler (figure 2).
The sound synthesis class library is a collection of C++ classes, each of which specifies a particular synthesis algorithm and defines a standard class interface. We envision the sound synthesis class hierarchy as an "open" architecture, enabling addition of customized synthesis algorithms and extensions of current algorithms based on particular rendering and optimization requirements. Currently, the library is extendible only at the source-code level. In a future version, however, it is anticipated that this extendibility will be realized through implementation as an ActiveX container. ActiveX is a Microsoft construct that allows different applications to exchange information and for one application to embed itself into the other, thus becoming, in effect, a component of it. As ActiveX controllers, sound synthesis libraries could literally be "dropped into" AREAL and thus become one of its synthesis libraries. This kind of extendibility holds great promise for the future of audio applications in general and for auditory display in particular.
Sample underflow (which can cause annoying clicks in the audio signal) is handled through a facility called the OctaneMeister. The OctaneMeister anticipates possible sample underflow by monitoring CPU load. When this load nears 100 per cent, the OctaneMeister tells the list of instantiated synthesis objects to lower its computation "octane." Each synthesis object has its own method for reducing its octane which is defined within the class from which it is instantiated. Moreover, synthesis objects are ranked in order of complexity: those whose performance would be most seriously compromised through the lowering of its "octane" are placed at the bottom of the list.
The C-language "wrapper" forms a shell around the Scheduler and the
Synthesis Engine. It exports a set of C functions to the client application.
This set of functions is referred to as the "API." The API constitutes
the sole interface between the application and AREAL (as depicted by the
single bar connecting the APPLICATION and the Wrapper in figure 1).
The motivation for defining the interface as a C-language API, rather than
allowing the application to interface directly to the C++ library classes
within AREAL, is to make the interface as simple as possible to use and
to allow for applications written in languages other than C++ to be linked
to the library. Functions defined within the API instantiate synthesis
objects, set up of data-to-renderer mappings, and handle control messages
to individual synthesis objects.