Requirements for a spatial sound authoring toolset on which we have concentrated are
When developing an authoring tool for spatial sound, the underlying system, described by the spatial sound API, defines a lot of the functionality and might restrict the generality and portability of the application. It is important to keep in mind that the main task for the author is to develop content, and that rendering issues across different platforms should not interfere. An example of modeling rendering issues was given in [Brown-Allard97]: the attenuation of the frequency spectrum of a waterfall (part of a ``Jungle Island'' demonstration) was modeled by two sound sources with different audible ranges and frequency bands. This made it possible to hear the rumbling of the waterfall in the distance as well as high frequency components when sufficiently close. The effect was impressive, but what if the sound renderer supports distance-dependent frequency attenuation? Would not it be better if the API and also the sound authoring tools hid such details from the user? The same philosophy can be taken for sound occluders and first-order reflections.