Does FMOD internally manage channel priorities based on 3D distance/volume as well as user defined priorities?

For example, if all the sounds playing are of the same priority and a new sound is played of the same priority, will the most distant/quiet of the current playing sounds be ‘swapped’ (I know it’s not the right word, but gives the right idea) with the new sound to play?

I’m asking because I’m integrating FMOD into a project which will have many concurrent sounds and I’m curious of whether I should handle this myself or if FMOD already supports something similar.

Other question:

I’m also worried that a lower priority sound (say air conditioning noise in a building compared to a gunshot) which is very close to the listener will get cut out because a very distant (and faintly audible) gunshot goes off. I think a distance based priority multiplier would work well in such a case. For example, the base priority of the gun sound is 255 and that of the air conditioning is 100. You find the max audible distance based on the rolloff setting and find the channel’s priority based on: (distance to noise emitter/max audible distance) * base priority. Based on the docs, it seems like nothing of the sort is supported (and maybe isn’t needed? am I missing something in my reasoning?) will it be in the next version?

You know… I’ve been wondering about that myself too. Sounds volumes don’t really drop off linearly, and some very loud sounds would change their frequency characteristics along with the volume.

In my opinion, if the sound library already figures out all of the non-linear concepts of sound sources, it would be the best component to prioritize the sounds. I mean, we already feed the 3D information to the sound system.

I guess one issue would be streaming buffers… (you can never tell if a stream will become much louder down the line). To some degree it’s a chicken and the egg problem… how do you know how significant a sound is going to be unless you consider the sample data, the distance / position, it’s velocity, and the union of all the other sounds that would be mixed together, without actually just doing most of the work that would have gone into preparing that sound.

One of the problems of doing this yourself, is that your model of how significant a sound is, may not correspond to that of the underlying sound engine. So when you get it wrong (by using a linear scaling factor), you might decide that a sound is significant when in reality it’s inaudible, and meanwhile another sound might have been better to play.

Good question… I’d to know the answer to this as well. I’m also guessing that if you end up using hardware 3D sounds, that the result will be different from than if fmod was doing the 3D computation in software. So how do you decide as the API user which sound will be the most significant?

Perhaps a simplistic model (such as ‘percieved sound importance’ over the distance to user is a reasonable measure) is good enough.

Well, it seems to make sense that you should be able to order a set of priorities. Like maybe first by priority value, then by volume, then by distance (or whatever order makes sense for you). Being able to set how priority management works would be relatively ideal.

I’ve talked to Brett about that before, and he said it’s something he could implement. I’d sure love to see that in a point release for FMOD, as it’s something I’d have to implement anyway, though it’d make considerably more sense if FMOD had built-in support for that method of priority handling.

The mod Brett referenced would be perfect, with one small problem. The 3D parameters for a channel can not be set until after you get the channel handle back from FSOUND_PlaySound. The result is that a newly played sound will always bump out the most distant sound of the same priority because the default location of the newly played sound is the listener position. Thus, it will virtually always be closer than any other sound. So, even if the sound I am wanting to play “will be” further away than any other playing sound, it will still bump something.