# Does SteamAudioSource strictly require FMOD Event Emitter, and how to handle dynamic event paths? **URL:** \ **Category:** Unity\ **Tags:** unity, csharp\ **Created:** [September 17, 2026, 6:57pm UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518 "2026-09-17T18:57:05Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Royal6](https://avatars.discourse-cdn.com/v4/letter/r/4af34b/32.png) [@Royal6](https://qa.fmod.com/u/Royal6)\ **Post date:** [September 17, 2026, 6:57pm UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518/1 "2026-09-17T18:57:05Z")
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! ---
**Author:** ![Connor\_FMOD](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/connor_fmod/32/3685_2.png) [@Connor\_FMOD](https://qa.fmod.com/u/Connor_FMOD)\ **Post date:** [September 21, 2026, 4:26am UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518/2 "2026-09-21T04:26:22Z")
Hi, Could I please grab your FMOD integration version. I am not sure I follow the issue. > [@Royal6](#): > > 1. **Is `FMOD Event Emitter` strictly required for `SteamAudioSource` to function** , or is there a way to feed a dynamically created `EventInstance` into it? Have you added the source to the event in FMOD Studio ![image](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/e/efda7ef1136ec06a6380c450cdc865e57e2e76ea.png) Or is this in Unity? If in Unity, how are you playing the audio and interacting with the `SteamAudioSource`? > [@Royal6](#): > > 1. 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? 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. ---
**Author:** ![Royal6](https://avatars.discourse-cdn.com/v4/letter/r/4af34b/32.png) [@Royal6](https://qa.fmod.com/u/Royal6)\ **Post date:** [September 21, 2026, 7:09pm UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518/3 "2026-09-21T19:09:25Z")
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: ```csharp 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(); } ``` ---
**Author:** ![Connor\_FMOD](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/connor_fmod/32/3685_2.png) [@Connor\_FMOD](https://qa.fmod.com/u/Connor_FMOD)\ **Post date:** [September 21, 2026, 10:15pm UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518/4 "2026-09-21T22:15:33Z")
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. ---
**Author:** ![Royal6](https://avatars.discourse-cdn.com/v4/letter/r/4af34b/32.png) [@Royal6](https://qa.fmod.com/u/Royal6)\ **Post date:** [September 21, 2026, 11:31pm UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518/5 "2026-09-21T23:31:20Z")
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? ---
**Author:** ![Connor\_FMOD](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/connor_fmod/32/3685_2.png) [@Connor\_FMOD](https://qa.fmod.com/u/Connor_FMOD)\ **Post date:** [September 28, 2026, 2:20am UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518/6 "2026-09-28T02:20:55Z")
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? - [FMOD Studio | Instrument Reference - Programmer Instrument](https://fmod.com/docs/2.03/studio/instrument-reference.html#programmer-instrument) - [FMOD Studio | Dialogue And Localization - Audio Tables](https://fmod.com/docs/2.03/studio/dialogue-and-localization.html#audio-tables) ---
**Author:** ![Royal6](https://avatars.discourse-cdn.com/v4/letter/r/4af34b/32.png) [@Royal6](https://qa.fmod.com/u/Royal6)\ **Post date:** [October 1, 2026, 9:58am UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518/7 "2026-10-01T09:58:22Z")
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: ```csharp 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. ---
**Author:** ![Connor\_FMOD](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/connor_fmod/32/3685_2.png) [@Connor\_FMOD](https://qa.fmod.com/u/Connor_FMOD)\ **Post date:** [October 6, 2026, 3:00am UTC](https://qa.fmod.com/t/does-steamaudiosource-strictly-require-fmod-event-emitter-and-how-to-handle-dynamic-event-paths/24518/8 "2026-10-06T03:00:08Z")
Thank you for sharing the code, I would add a [FMOD Engine | Studio Api System - Studio::System::Flushcommands](https://fmod.com/docs/2.03/api/studio-api-system.html#studio_system_flushcommands) after clearing the instance to make sure that reference has finished clearing before trying to reassign it. Otherwise it looks great.