At the core of the audio propagation system, there are two essential components: the emitter and the director. The emitter is responsible for defining user parameters and calculating instance-specific values needed for occlusion and obstruction. The director is responsible for controlling how the sound sources are processed by the audio engine and contains the majority of the functions and logic used by the emitters. A well-designed core system is important as it allows for consistent and scalable audio behaviour. Designing these core components to be deeply customizable allows a developer to fine-tune their behaviour according to their needs.

Prior to this project, I had experimented with alternative system designs for calculating occlusion, one of which relied on the director component for all functionality. However, this presented a major issue when interfacing with FMOD, as without access to the specific instance of the event being occluded, local parameters could not be used to control the DSP processing for occlusion. The system instead relied on the use of global parameters, meaning that a unique global parameter would be required for every event instance. This major flaw led to further iteration, resulting in the emitter-director based system that this project is based upon.

Emitter-specific customizations are available to modify on each instance of the emitter component, whereas system-wide customizations are accessible on the audio director component. Each emitter accesses the function “Update Occlusion” from the director component so that all sub-functions remain centralized on the director, in case of potential future derived components that will also need to access the same functions as the base emitter class.

This propagation system is designed to be forward compatible with multiple audio engines. To achieve this, the director component allows a developer to select their chosen engine from an ENUM, which is then derived by the emitter component to allow for audio engine-specific compatibility to be used. An example of this is the custom FMOD Audio scene component shown above, which allows for runtime parameter modulation. To reduce scope, this project will only include support for use with FMOD; however, the system will be designed so that additional audio engine support could be added modularly, with the inclusion of error handling and warning messages when a currently unsupported audio engine is selected.