Rendering classes¶

The audio rendering in VA is done on the basis of source-receiver pairs. This means, in every processing step, one audio block is rendered for each source-receiver pair which are then superposed to create the final output stream. This, for example, allows muting sources and/or receivers during runtime. The output depends on the position and orientation of the respective sources and receivers as well as the utilized rendering class and its parameters. Generally, those classes are based on two rendering concepts: Sound-path-based and FIR-based rendering, which are introduced below.

In version 2022a, there has been a revision of the internal concept of the renderers. One of the goals was to lose the restriction of sound-path-based renderers using a fixed type of spatial encoding, which was typically binaural filtering. Now many renderers allow the user to specify this type in the VACore.ini - i.e. binaural filtering, Ambisonics, VBAP. In the context of this revision, some renderers were marked deprecated, removed or renamed. For example, the VBAPFreeField renderer has become obsolete as the FreeField renderer allows the user to select a VBAP encoding. Some renderers are still restricted to a binaural processing but might be changed in the future.

In the following, an overview of all rendering classes will be given. Then, some general rendering concepts are explained before discussing the individual rendering classes in detail. This starts with the "renderers" which are simply routing an input signal before introducing the sound-path-based and the FIR-based renderers.

Rendering class overview¶

N-channel renderers¶

The following renderers are not restricted to a fixed number of channels. The number of channels can be set by the user and typically depends on the utilized spatial encoding technique (binaural synthesis, Ambisonics-encoding, VBAP-encoding).

Binaural renderers¶

All of the following renderers have a binaural two-channel output stream.

Deprecated, removed or renamed renderers¶

Due to a new renderer structure introduced in version 2022a, some renderers are marked as deprecated and might be removed in future versions.

The following renderers were renamed to better reflect on their purpose.

General rendering concepts¶

Most renderers share some general concepts. This includes a motion model for source and receiver and a variable-delay line allowing to model the Doppler shift. Both can be configured in the VACore.ini.

Motion model¶

Since VA is primarily designed for real-time auralization, motion of sources and receivers is handed as discrete samples of position and orientation which are called motion keys. In this way, it is possible to handle arbitrary movement including data from tracking devices. However, this requires to interpolate the discrete data within VA to guarantee a smooth movement. For this purpose, the rendering modules in VA use a motion model which interpolates the motion keys using a triangular sliding window. As a result, the motion data used for the rendering process slightly varies from the actual data. Most important to mention is the slight delay being introduced to the motion data.

Variable delay line¶

VA's rendering modules use variable delay lines (VDLs) to apply the Doppler shift to the input signals. A VDL is a long buffer with a reading curser which can be moved during run-time. In this case, the reading curser refers to the sound propagation delay. By not hard-switching between curser positions but virtually stretching/compressing the audio samples via interpolation, a Doppler shift is modelled.

Propagation parameter histories¶

An additional rendering concept, is provided in the so-called data history buffers. These are used to delay and interpolate propagation parameters, such as spreading loss, propagation delay or air attenuation, for sound-path-based renderers. This is especially relevant, when using computationally complex sound propagation simulations, which needs to be scheduled into a seperate thread. Currently, this is only used in the AirTrafficNoise renderer.

General configuration parameters¶

Most renderers share some general parameters which can be configures in the VACore.ini. Typically, all renderers already use proper default values for the parameters and should only be modified if really necessary.

Similar to the source motion model parameters there are parameters for the receiver, e.g. ReceiverMotionModelWindowSize.

Routing-based renderers¶

AmbientMixer¶

The AmbientMixer is not a rendering module in the original sense. It does not consider source and receiver motion at all but only uses the sound source power to apply a gain to the input signal. Thus, the general rendering concepts do not apply to this renderer. Its purpose is to add ambient sound to virtual scenes by combining it with additional rendering modules. Typically, those ambient sounds are taken from .wav files which are pre-recorded or pre-simulated.

Important: Although the actual positions of source and receiver are not relevant to this renderer, an initial position must still be set so that the source and receiver become valid.

Sound-path-based renderers¶

For sound-path-based rendering in VA, each source-receiver pair holds a set of sound paths, which are processed separately. The number of considered sound paths depends on the respective rendering class. Instead of using FIR-based convolution, most sound propagation parameters are applied using filterbanks based on one-third octave magnitude spectra (typically IIR filtering). This includes source directivities or air attenuation. Only for binaural rendering, a full FIR convolution of the rather short head-related impulse responses (HRIRs) is done.

Common configuration parameters¶

Most sound-path-based renderers share the following VACore.ini parameters. Most importantly this includes the settings for the spatial encoding. Note, that for binaural renderers, the spatial encoding type cannot be changed by the user which makes the settings for ambisonics and VBAP obsolete.

FreeField¶

As the name suggests, this renderer assumes free-field conditions for the sound propagation based on the homogeneous medium. Therefore, it only considers a single, straight sound path per source-receiver pair which makes it extremely efficient. Based on the direction and length of this sound path, the following auralization parameters are evaluated and applied to the input signal:

• Source directivity
• Spherical spreading loss
• Propagation delay / Doppler shift
• Air attenuation (ISO 9613-1)
• Spatial encoding at the receiver (Binaural / Ambisonics / VBAP)

BinauralFreeField¶

This renderer has three major differences compared to the FreeField renderer. Most importantly it is restricted to a two-channel binaural output stream. Additionally, it does not support the consideration of air attenuation. However, the special feature of this renderer is to use individualized HRIRs adjusting the ITD. For this purpose, the receiver has to get additional anthropometric data which can be applied while setting up the scene.

AirTrafficNoise¶

In addition to the direct sound, this renderer considers a second sound path for the ground reflection. Assuming a flat ground at a certain altitude (typically y = 0), this sound path is calculated based on the image source method. The renderer is primarily designed for aircraft flyovers as the assumption of a half-space is quite reasonable for sound sources at high altitutdes. However, it can also be applied to other scenarios where this assumption is suitable (e.g. car pass-by*).

The special feature of this renderer is, that the sound paths can either be based on the homogeneous medium in VA or simulations by the Atmospheric Ray Tracing (ART) framework. The latter considers an inhomogeneous, moving medium which leads to curved sound paths. This is particularly relevant for those flyover scenarios. However, it should be noted that the simulation has certain limitations cannot be applied to every combination of source-receiver positions (see Limitations section in this paper).

Based the respective sound paths - either straight or curved - the following auralization parameters are evaluated and applied to the input signal:

• Source directivity
• Spreading loss
• Propagation delay / Doppler shift
• Air attenuation (ISO 9613-1)
• Turbulence (temporal amplitude-variations)
• Ground reflection factor
• Spatial encoding at the receiver (Binaural / Ambisonics / VBAP)

_{*When dealing with short distance scenarios like a car pass-by, it might be a good idea to disable the turbulence (see auralization modes).}

Special configuration parameters

OutdoorNoise [BETA]¶

This renderer is currently on a beta version. Documentation will be updated in the future...

FIR-based renderers¶

FIR-based rendering considers all relevant sound paths - i.e. connecting a source with a receiver - using a single FIR filter. This makes sense, when the number of sound paths is extremely large (e.g. in room acoustics). A limitation, however, is that the individual acoustic properties cannot be separated anymore.

Common configuration parameters¶

Most FIR-based renderers share the following VACore.ini parameter.

GenericFIR¶

This renderer convolves a user-defined FIR filter for a configurable number of channels for each source-receiver pair. Consequently, the source and receiver position are irrelevant for this renderer and the general rendering concepts do not apply. The filters are set for each source-receiver pair using the respective binding and can be updated in real-time.

Important: Although the actual positions of source and receiver are not relevant to this renderer, an initial position must still be set so that the source and receiver become valid.

BinauralArtificialReverb¶

This renderer implements an efficient method to add a reverberation tail a virtual scene. It does not consider the direct sound or early reflections and should therefore be combined with other renderers. For each given reverberation time (defined for a corresponding frequency range), exponentially decaying room impulse responses (RIR) are created with increasing reflection density over time (~t²). Spatial information is applied separately to each inserted impulse by randomly selecting a HRTF. Eventually, to generate one broadband RIR each frequency dependent RIR is combined in the frequency domain by using low pass, band pass and high pass filters. Parameters regarding the position and angle can be chosen to control when a new artificial reverberation filter (new random directions) should be generated.

Special configuration parameters

Note, that the NumChannels parameter is obsolete since this renderer's output is restricted to a two-channel binaural stream.

RoomAcoustics [NOT PUBLIC]¶

This renderer is designed for real-time auralizations of room acoustic scenarios using physics-based simulations. For each source-receiver pair, a room impulse responses (RIR) is requested frequently. The respective requests are scheduled and processed by the ITASimulationScheduler. While not all simulation requests might actually be executed, a real-time processing is feasible if the respective update rate is high enough. To increase the efficiency, the RIR is split into direct sound, early reflections and late reverberation which are simulated separately. On the one hand this allows, to have higher update rates for the early parts of the RIR which are most crucial for the localization of sound sources. On the other hand, the individual parts of the RIR can be en-/disabled in real-time which is a nice feature for demonstrations.

Currently, the only available room acoustic simulation backend for the ITASimulationScheduler is RAVEN. RAVEN is not open-source but available for academic purposes. Thus, the public version of VA does not include this renderer. In future versions, the ITASimulationScheduler might support additional simulation backends. Then, this renderer will become public (but still not include RAVEN).

Special configuration parameters