I would like to be able to fade out a sound after a set delay (e.g. 2 seconds) independent of the duration of the sound. I’m dealing with an extreme case where I’m getting flooded with too many long duration sounds, and believe I’m running out of channels.) I’ve currently got a solution where I stop adding sounds once the CPU gets to a certain level, but I’d rather just fade out the sounds that are already playing (they are just resonating, and you can’t hear it among 64 sounds.)

I tried FMOD_Channel_SetDelay on the end time, but that results in a click (which is expected). I’m wondering if there’s an easy way to get a smooth fade out and make the channel available. Precision is not important. It just can’t click, and it has to happen after about a second or two.

I’m currently using 2D sound, but one idea I have is to use 3D sound and setup the sound with velocity vectors away from the listener and use mindistance rolloff. That way the sound level stays flat for 2 seconds then fades as specified by the rolloff parameters. (I’m a bit concerned about the additional CPU overhead.)

I had thought to use a timer to just reduce the volume after a set of delays, but I don’t have an easy way to set up a timer within the sound queue thread that talks to FMOD.

Am I missing an obvious technique?

  • You must to post comments

Hi richardl,

I think the easiest way would be to keep a list of channels and just poll their position each update and use setVolume to make them fade out.

the code would look something like this:
fadeOutStartTime = 2000 (ms)
fadeOutEndTime = 2500 (ms)
fadeOutDuration = fadeOutStartTime – fadeOutEndTime

for each channel
pos = chan->getPosition
if (pos > fadeOutStartTime)
progress = (pos – fadeOutStartTime) / fadeOutDuration
chan->setVolume(1.0 – progress);

This would give you the added benefit of allowing you to make the fade out logic more sophisticated like only fading out when there is more than certain number of channels playing at the same time.

Hope this helps.


  • You must to post comments

Thanks peter.

That would probably work. I’d have to create some sort of mechanism to keep a list of all the active channels and make that list available at the queue (where I do update).

In the mean time I came up with a system where I’m setting channel priorities based on sound length. Longer sounds have a lower priority. Then I reduce the number of audible sounds to number of sounds playing whenever the CPU usage hits a threshold. (When we drop below the threshold I reset the audible sounds to 64.) I also set the sound group behavior to MUTE with a 1 ms fade. I also still stop adding new sounds when the CPU level gets about 15 percent higher than my cap threshold.

It’s not the same effect, but it seems to work well to keep the more important sounds playing and keep things from breaking up (when CPU use gets too high).

One thing I’m curious about is the relative weighting between sound volume and priority in determining when a sound will go virtual.

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.