StudioEventEmitter SetParameter() GC

[SonarSoundSB]

Hello,

We’re using StudioEventEmitters for the bulk of our implementation and have noticed a lot of GC coming from them when setting parameters due to the params list lookup etc I’m guessing. This is much more noticable on parameters we set each frame of course and for things like occlusion (as seen in the screenshot below) can be quite a lot when dealing with multiple sounds.

I’ve made an extension method for the emitter which basically just ignores the list lookup

The developer would like to know if this is a safe alternative and/or if there’s any way to avoid GC by just using the raw StudioEventEmitter code?

Thanks for your time!

[cameron-fmod]

Apologies for the delay.

The StudioEventEmitter.SetParameter function uses a cache for the parameters but only when StopEventsOutsideMaxDistance is enabled, otherwise it would not keep track of the parameter changes when an event goes outside of max distance then comes back. This does incur some GC overhead as you have found.

What you have done is perfectly fine, as long as you are aware that the parameters could behave strangely when going in/out of max distance.

[SonarSoundSB]

Thanks Cameron!

Ahh okay makes sense, we are using StopEventsOutsideMaxDistance but I assumed if the event is being stopped outside it’s max distance then it would have been released and therefore the parameter changes won’t affect that instance anyway, isn’t that the case?

I see there’s a cache solution to this problem here, should I implement something like this?

StudioEventEmitter.SetParameter creates Garbage

Here is the dirt simplest way. Just install a cache between the parameters public static class FmodFix { private static Dictionary<string, byte[]> StringTable = new Dictionary<string, byte[]>(); public static byte[] Encode(string name) { byte[] results; if (!StringTable.TryGetValue(name, out results)) { results = Encoding.UTF8.GetBytes(name + Char.MinValue); StringTable[name] = results; } return results; } } public RESULT setParameterValue(string name, float value) { …

Thanks Cameron

[cameron-fmod]

@SonarSoundSB

we are using StopEventsOutsideMaxDistance but I assumed if the event is being stopped outside it’s max distance then it would have been released and therefore the parameter changes won’t affect that instance anyway, isn’t that the case?

It does get released but the intention is to reapply the parameters if/when the event comes back into range. Otherwise the event will use either the default parameter values or the values set in the editor.

As for the GC, I have made a couple of tasks for addressing the allocs generate by the current code and we will hopefully have those fixed in an upcoming release.

[fendercodes]

I’m also very keen to have those GC allocations addressed when you have time as we were calling this code every few frames to set parameters for certain events that need frequently updating. Keep us posted. Thanks!