95 torchs -> 91 instances -> 85 instances playing. Why?

In a test map, we have 95 torchs, which are associated with an event instance of the same event, which are all started at the beginning (and loop indefinitely).
It’s a simple 11 sec mono loop, spatialized. I removed the streaming, because I guess streaming 95 instances of the same event at the same time sounds like a bad idea.

In the profiler, I see weird numbers:

  1. “All instances” is < than what it should be
  2. “Playing” instances is < than “All instances”
  3. “Active” instances is < than “All instances” (this is in line with the virtualization I configured on this event)
  4. “All” and “Playing” seem to change if I set the event priority differently

I’d like to know what should be looked as bugs in our game (maybe point 1. - we’re using API in MOAI engine), and what is FMOD normal behavior (maybe point 2.). It’s a simple event, I would be a bit surprised if FMOD should kill some instances of it (since I’m testing the game on a decent PC).

To clarify:

  • “All instances” is all event instances, including event instances that are virtualized or stopped.
  • “Playing instances” is all event instances that are not stopped, including both virtualized event instances and active event instances, but not event instances in the stopped play state.
  • “Active instances” is only those event instances that are both playing and not virtualized, and so does not include stopped instances or instances that have been virtualized.

It’s therefore normal for “active instances” to be less than “playing instances” and for “playing instances” to be less than “all instances,” because “active instances” is a subset of “playing instances” and “playing instances” is a subset of “all instances.”

FMOD is more likely to temporarily virtualize instances than to kill them entirely, and the quality of the PC does not usually have any impact on how many event instances FMOD kills or virtualizes. Instead, FMOD’s stealing and virtualization behavior is governed entirely by your game’s settings. (This is to allow you to customize how much of your resource budget your game’s audio consumes.) For more information, see our documentation on virtual voices, the max instances event macro, and bus instance limiting.

As for why you have 91 event instances instead of 95, I’m afraid I can’t be sure without more information. What value is System::setSoftwareChannels set to in your game’s code?

No it’s not, because as I said, all instances created are started (and loop forever) at the beginning of the map. Could you confirm we should look that in our code rather than in FMOD settings? The weird thing is that I get different playing instances when I change the event priority; but this could be random, I’m not absolutely sure.

I’m gonna check that… But it’s probably to default values, since I didn’t ask anything to the dev for this.

My apologies, I should have said "It’s therefore normal for playing instances to be less than or equal to all instances.”

Yes. In a situation where all instances are created and started at the beginning of the map and loop forever, the number of playing instances should not be lower than the number of instances created unless they’re being culled for some reason, and the limits on instances and voices are usually set in code rather than in FMOD Studio.

This isn’t necessarily weird, depending on the content of your events, which events’ priorities your changing, and why your instances are vanishing in the first place. For example, an event instances may have multiple voices if it contains more more than instrument or triggers some instruments more than once, so altering the priority of events may change how many voices are being consumed by the highest priority events and thus how many lower-priority event instances need to be virtualized or culled.

Again, though, it’s impossible for me to know the cause of the behavior you’re seeing without more information.

1 Like

In a test map, we have 95 torchs, which are associated with an event instance of the same event, which are all started at the beginning (and loop indefinitely). It’s a simple 11 sec mono loop, spatialized. I removed the streaming, because I guess streaming 95 instances of the same event at the same time sounds like a bad idea.

Is there a Max Instances limit set in the event macros or is it infinite?

Is the purpose of this test map to be a stress test? Because 95 simultaneously playing instances of the exact same sound seems far from optimal for game content. There’s also a risk of phasing / flanging if it is the same mono sound started at the same time in 95 instances. As you move around the scene and instances get un-virtualized the sounds may not be exactly in sync.

It would be a far better approach to set the max instances to something like 5, and the Stealing to Virtualize. This way the nearest 5 torches will always be audible, and as you move around, the further away ones get virtualized and the closer ones become audible. All the while the polyphony stays reasonable.

To add variety and eliminate phasing (so that they sound like different torches in different positions instead of a two-dimensional full coverage), you can apply some pitch randomization and full Start Offset randomization to the torch sound, so that they all start at different points of the loop. However there is still a slight chance of phasing.

A better approach still is to split the torch loop into short 0.1 second slices (by transient / zero cross - Reaper can do this automatically), export them to wavs and add them to the Multi-Sound’s playlist, and set the playlist to loop with shuffle. This will continuously, gaplessly daisy chain the samples one after another in random order and give plenty of variety with next to no chance of phasing between torches.

I’ve already set it as you said: steal=virtualize, max instances=6, and offset to 50%, 100% randomized. That’s why I didn’t mention the active instances shown in the profiler, because this one works as expected (it shows 6). We still have to find why the other numbers don’t match, but the dev haven’t time for that at the moment.
Thanks for the slicing by transient trick, I keep that in mind!