we’re working on a racing sim and we’ve had a ton of problems with FMOD virtual voice system. We create a lot of events, and thus lots of Software channels, each with accurately tuned and tested min and max distances, volumes, positions in the 3D world, etc. We thought the library could work out with relative ease which Soft channels elect to be Real channels with these informations, as the documentation says; however, it never worked well, for example we kept having the engine of the player’s car (that has higher priority and is just in front of the camera) going silent for some fractions of a second, because an opponent’s engine was being picked up as a Real voice even though the opponent was at the other side of the track. We’re pretty sure this was reason, because we carefully looked at the FMOD Profiler and the performance stats; the player’s car engine is a specific event that is the only one with “High” priority, and still it was turned off (i.e. it was grey in the profiler graph).
In the end, we pretty much fixed the problem by calling stop() on the events whenever their distance from the listener was greater than their max distance (common sense would suggest the library would do that - why even consider a Soft channel to be Real if it belongs to an event that is outside max range?)
However, we still have another problem now. The car that the player is driving (or, better, the camera is focused on) has a richer sound than the others, i.e. we create more events for it, for example trasmission noise. If the player switches camera from a car to another, we stop() those “extra” events on the old car and start() them on the other. The problem happens when you’re on the starting grid: if you switch from car to car and then return to your own to start the race, the number of virtual channels (as shown in FMOD Profiler) is very high, much higher than before switching the cameras around, and I hear those “click” sounds of old due to having too many channels (and the library not being able to pick the important ones). I can see those events that were started and then stopped still lingering in the profiler graph view.
I would expect calling stop() on a event to pretty much kill it good, if not in terms of memory usage at least in terms of scheduling and occupancy of slots in the virtual voice system. Can you shed some light?