Posts Tagged 'Code'

artifacts and other OpenAL issues

When using the OpenAL library for audio output, you might experienced playback problems such as sound artifacts, “clicks”, volume problems, etc. Here a list of hints that might help:

  • Always set the correct gain, position, etc _BEFORE_ calling alSourcePlay(). Otherwise OpenAL might output the first milliseconds of the sound on a totally wrong position using a wrong gain, etc.
  • Always check for errors when creating new sources. If you blindly use an invalid source you might hear the sound from some weird position or you might not hear it at all. Make sure your error handling code addresses all possible issues.
  • Ensure that your sound files (e.g. WAV) aren’t broken. I once used a wav sound that worked well in players like VLC but in OpenAL it just played at full gain all the time, no matter what distance I set. The solution was to edit the wav and to reduce the overall volume of the sound into a valid range.

To be extended some day..


OpenAL with multiple distance models

OpenAL is a great library to manage 3D surround in your application. For the FPS game AssaultCube I rewrote the sound related code to use OpenAL instead of simple stereo output. There are different distance models to calculate the effective gain (volume) of the sound sources: inverse distance, exponential distance, linear distance, etc. For FPS games the inverse distance models seems to fit best, it just sounds more realistic than simple linear models. Now the problem with inverse models is that no matter how far away the sound source is, the volume will never completely drop down to 0, you will always hear it, this is a real issue:

  • Processing almost silent sounds is a waste of resources that could be used otherwise. The sound channels for mixing are usually limited to 32 (!) on most hardware.
  • You can not limit the sound to a specific radius e.g. to make it present in a single room/area only.

Now you could just disable the distance model using alDistanceModel(AL_NONE) and write your own code to handle all gain calculations yourself. However for AssaultCube I found a better solution, the important sources in the game such as sounds from players are using the inverse distance model, on the other hand all map sound entities that are placed in certain areas as well as low priority sounds such as footsteps use my own distance model. Because OpenAL allows only one distance model to be active, we need to bypass the distance model calculation for these sounds:

alSourcef(id, AL_ROLLOFF_FACTOR, 0.0f);
alSource3f(id, AL_POSITION, 0.0, 0.0, 0.0);

This way the source is always on the same position as the listener, causing the gain value to stay at the maximum. Now that we know that OpenAL won’t touch this source’s gain anymore, we can calculate it using our own rules:

float dist = camera1->o.dist(vec(e->x, e->y, e->z));
float gain = 0.0f;
// clamp to full gain (attr3 is a object "size" property)
if(dist <= e->attr3) gain = 1.0f;
// linear calc (attr2 is a "radius" property)
else if(dist <= e->attr2) gain = 1.0f - dist/(float)e->attr2;
alSourcef(id, AL_GAIN, gain);

Now this object uses our own linear model while the other more important objects still rely on the better but expensive inverse model. I think this is the best solution to the problem regarding code size and simplicity.