Active voices and virtualization

[_MaX]

Hi FMOD Team!

I’m starting to seriously try understanding the profiling system and ensure we’re preserving proper performances in our game.

I realized this morning that I had a bunch of events that are triggering a huge amount of simultaneous active voices. I’m not sure I understand the reason.

I have an event with a couple of sounds over several tracks simulating insects around the player. It looks like this:

This event is configured like this:

And I made an empty map in UE5 with the sound in the middle of the area. I’m placing myself as the player far outside the max distance radius.

The thing is, I still see the active voice popping up everytime the loop restarts. Like this, with a single sound, it’s not really critical. But now imagine this event used in a huge map where you can have 90 or more blueprints containing it. The number of virtual voices is around 200 and the spike for the active voices gets to around 45 / 60 just for this particular event.

The initial setup was with a max distance of 40, so I tweaked it to 10 thinking it would reduce the amount of active voices… but it still happens.

So there are two possibilities:

• I’m either vastly misunderstanding the concept of voices or the way to read it
• I made a mistake on the configuration of the event to avoid that phenomenon

The next question is: let’s say it’s normal. What’s the cost of that? Should I be afraid of a behavior like this if the voices are indeed properly virtualized?

Thank you in advance!

[jeff_fmod]

The FMOD Studio Max Instances setting controls voice stealing in relation to event instances. This can be viewed by selecting the Instances graph option. The Voices graph however is actually displaying the number of underlying Channels that your instruments are controlling. The reason you are seeing huge amounts of voices is because you have the “Virtualize” voice stealing option set, which means that all of your events will be playing virtually.

Events that are playing virtually consume very few CPU resources, as the only processing that is actually done is updating their playback position so that they can resume playback from the correct position once they become unvirtualized. Expensive operations such as reading sample data, performing DSP calculations, and file IO are all skipped when an event instance is virtualized, so there should be no cause for concern. This can be verified by clicking the CPU: Mixer graph option, which should be remaining steady throughout virtual voice growth.

If you are finding that the CPU: Mixer graph displays an unacceptable amount of CPU usage, you can try one of the other voice stealing options, such as “Oldest” or “Furthest”, which completely stop event instances outside the max distance, and should have no overhead at all.

[_MaX]

Hi Jeff! Thank you for your feedback.

I indeed had a good grasp of the virtualization vs non-virtualized events. That said, your answer is making me question myself about that actual understanding

So a couple of other questions:

• To better understand the processes behind, what does this spike means in term of computation? It seems that it is quite short ( we’re talking milliseconds ). Is it like FMOD trying to playback the voices during virtualization and immediately stopping them since the event is actually virtualized?
  Does this mean we should account for this super short active voices as normal un-virtualized voices?

• You are talking about Oldest/Furthest stealing modes, but as I was mentionning in my first post. This event is meant for simulating insects in the environment. Which means, it is always placed in the map and should be playing when the player reach the area.

The problem is, virtualization is mandatory for that case unless I’m missing something.
From my understanding, any other stealing option besides virtualize is only good for fire and forget (one shot) events.

I did a test again to ensure I wouldn’t say something wrong, but as soon as the event is set to furthest (imagining the closest event would play), when I start PIE in UE, only the two first event play. And if I move close to events far away from these, they never “steal” those instances.

So if I did understand the system properly, it means my only alternative is virtualize. That said, if we take the 18.7 Stealing chapter of the documentation, it does not feel like the stealing oldest/furthest should not work for static environmental sounds… I always found that strange.

The question I’m asking myself is: how do they do with insanely huge enviros in AAA open worlds with situations like that? Do they have another culling system on top of FMOD’s virtualization system stopping the events to avoid reaching the 512/1024 max voices?

Our maps are not small, but it’s not an open world. Still, with 90 blueprint containing that single event. I’m reaching 200 inactive voices. Now imagining this with the final level of detail and way more audio details in the map… I’m pretty sure I would be far beyond the 1024 budget.

Last thing… I did this test with the live update enabled:

The white marker (where the blue square is) is the moment when I’m swapping the even from “furthest” to “virtualize”. If I’m following what you’re saying, virtualization should only happen when using virtualize right? How come I do see the exact same amount of inactive voices? Are the voices reserved as soon as an event exists in the map and does not particularly means “virtualized”?

[jeff_fmod]

@_MaX

Is it like FMOD trying to playback the voices during virtualization and immediately stopping them since the event is actually virtualized?

Yes, that is essentially what is happening.

@_MaX

Does this mean we should account for this super short active voices as normal un-virtualized voices?

These voices are non-virtual in that moment, and will contribute to your max instance / max virtual voice counts, and in large enough quantities could flog your CPU. I would be surprised if that was the main performance bottleneck in your game if you do get to that point though.

@_MaX

The question I’m asking myself is: how do they do with insanely huge enviros in AAA open worlds with situations like that? Do they have another culling system on top of FMOD’s virtualization system stopping the events to avoid reaching the 512/1024 max voices?

Some large projects choose to have global event culling systems for greater control over event spawning, but the majority of large projects don’t require this, because they don’t play all events at once or rely on virtualization to enable/disable sounds as you are doing. Instead, they use collisions to start events when the player is within range of the object making the sound, and stop the event when the player leaves that range.
Perhaps rather than playing all of your insect sounds at once and relying on virtualization to make them audible, you could use a Trigger Actor and start your insect event on Event Actor Begin Overlap, and stop it on Event Actor End Overlap.

@_MaX

If I’m following what you’re saying, virtualization should only happen when using virtualize right? How come I do see the exact same amount of inactive voices? Are the voices reserved as soon as an event exists in the map and does not particularly means “virtualized”?

Audibility doesn’t get recalculated until a new event instance is created, so if you change the stealing mode the profiler won’t show any change until a new event instance is created. I will get the Dev team to look into this and see if we can trigger an audibility calculation when changing the stealing mode- thank you for bringing this to our attention!

[apfelbaum]

I’d like to know this too as in my recent tests with over 500 virtualized voices i got mandatory problems with sound not playing at all, especially gameplay related sounds. But reducing these to around 70 without a change in active voices count all problems were gone.

[jeff_fmod]

The Total Channel Count in the FMDO for Unreal integration defaults to 512. This means that if you are already playing 512 voices, the 513th voice will do one of two things:

• Steal from another playing voice, that has the lowest audibility
• Not play at all if there are no voices with a lower audibility

If you are finding that you cannot hear voices that you are expecting to hear, it is because there are other voices already playing, virtual or otherwise, that have a greater audibility than your new voice. To get around this, you can try increasing your Total Channel Count in the FMOD Unreal settings to give your new voices more opportunities to spawn virtually, or you can optimize your audio usage, as you did by reducing the amount of simultaneously playing voices.

[apfelbaum]

I should check out the project settings more often.

I feel so dumb. Thanks for clarification.

Haha

[_MaX]

Hi Jeff,

Thank you very much for your answers.
I wanted to give a bit of feedback on our choices so that the thread helps other people in the future.

We’ve opted for a fast distance computation between the blueprints/assets and the player(s), instead of using triggers which are not ideal ( physics overhead, collision filtering and so on ).

With that implementation, I’m back to a 15 to 20ish active voices depending on the detail in the area instead of the 200+ I was mantionning in the earlier posts.

This means that even tho FMOD is a really great solution for virtualization of voices. As soon as you have a huge amount of audio details in a somewhat medium to big level (or obviously even open world). You are required to implement a custom culling system to keep good performances but also, control your mix and stealing properly.

Again, thank you for the support!