Does SteamAudioSource strictly require FMOD Event Emitter, and how to handle dynamic event paths?

Unity
,
1

I’m setting up a gunshot system in Unity using FMOD and Steam Audio.

I noticed that SteamAudioSource (for occlusion and reflections) seems to only work if there is an FMOD Event Emitter attached to the same GameObject.

My questions are:

  1. Is FMOD Event Emitter strictly required for SteamAudioSource to function, or is there a way to feed a dynamically created EventInstance into it?

  2. If it is strictly required, is there a recommended method to dynamically change event paths on an FMOD Event Emitter at runtime for object pooling? Right now, simply assigning a new event path and calling play doesn’t work, and it keeps playing the old sound. What is the best practice to handle this limitation?

Thanks in advance for any advice!

2

Hi,

Could I please grab your FMOD integration version. I am not sure I follow the issue.

Have you added the source to the event in FMOD Studio

image
image980×230 27.1 KB

Or is this in Unity? If in Unity, how are you playing the audio and interacting with the SteamAudioSource?

Is there any code snippets that you can share where you are implementing this?

Any repro steps or code that can be shared would be great.

3

Hi, thanks for the response! Let me clarify the issue.

All sources and events are correctly configured in FMOD Studio and work fine. The core problem lies specifically in the behavior of the StudioEventEmitter component.

It appears that StudioEventEmitter caches or locks in the EventReference value internally during initialization. Because of this, changing the EventReference field dynamically at runtime (even though the field is public, which implies it can be modified from the outside) has no effect the emitter keeps playing the old event or fails to switch.

Here is the pooling script I am currently using to manage sounds, where I try to assign the new EventReference on the fly right before playing:

public void PlaySFX(EventReference eventReference, Vector3 position, Priority priority)
{
    if (!CanPlay(priority))
        return;

    StudioEventEmitter emitter = pool.Get();
    emitter.EventReference = eventReference; // <--- Changing this at runtime does not update the internal FMOD instance
    emitter.transform.position = position;

    activeEmitters.Add(emitter);

    emitter.Play();
}
4

Thank you for the code. Unfortunately, the emitter was intended to be used with a single event. So changing its event reference after is has been used is not possible. An option could be creating and managing event instances yourself for a more dynamic system.

5

Yes, that’s exactly what I suspected, which is why I initially wanted to ask how to link sounds created via RuntimeManager.CreateInstance directly with SteamAudioSource.

As far as I understand, SteamAudioSource strictly requires the StudioEventEmitter component to function correctly (in order to process occlusion and reflections), and without it, the audio won’t play through Steam Audio properly.

That’s why the question arose: how is one supposed to properly handle object pooling for StudioEventEmitter if simply changing the EventReference on the fly doesn’t work due to internal caching? Are there any official best practices for this?

6

I see, could I please get some reproduction steps to set up a test Unity project scene to see if there is an alternative method on my side? Alternatively, if you are able to make a test project that would be a massive help.

Off the top of my head, if you only want to change the audio that the emitter is playing we could use a programmer instrument and either loose files or an audio table? Let me know if that is an option you would want to investigate?

7

Hi Connor, thanks for the clarification! I realized that StudioEventEmitter caches the event internally, so changing EventReference directly doesn’t rebuild the underlying instance.

To fix this for my object pooling system, I wrote a custom method that clears the cache and reinitializes the event data. Here is what I came up with:


        public void ResetEvent(EventReference newEventReference)
        {
            if (instance.isValid())
            {
                instance.stop(FMOD.Studio.STOP_MODE.IMMEDIATE);
                instance.release();
                instance.clearHandle();
            }

            EventReference = newEventReference;

            eventDescription.clearHandle();

            cachedParams.Clear();

            Lookup();
        }

My question is: Is this approach safe and robust regarding FMOD memory management and SteamAudioSource integration, or are there hidden pitfalls (like event instance leaks) that I should watch out for?

However, Programmer Instruments don’t quite fit our use case, because our pooled events have completely different FMOD parameters. Since all Programmer Instrument variants share a single event structure, we wouldn’t be able to control distinct parameters independently for each sound.

8

Thank you for sharing the code, I would add a FMOD Engine | Studio Api System - Studio::System::Flushcommands after clearing the instance to make sure that reference has finished clearing before trying to reassign it. Otherwise it looks great.