# Unreal Engine FMODAudioComponent Accumulation & Performance

**URL:** <https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715>\
**Category:** Unreal Engine\
**Created:** [November 26, 2025, 4:25pm UTC](https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715 "2025-11-26T16:25:39Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dzambrano](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dzambrano](https://qa.fmod.com/u/Dzambrano)\
**Post date:** [November 26, 2025, 4:25pm UTC](https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715/1 "2025-11-26T16:25:39Z")

</div>

**FMOD Version:** _(2.03.06)_

**Unreal Version:** _(UE5.5)_  
**Platform** : Mobile/Android/Meta Quest

Hello! We are experiencing **large spikes in CPU usage on the Game Thread** , traced specifically to **FMODAudioComponent** updates. These spikes occur even when:

- No obvious sounds are playing

- No gameplay events are firing

- The player is idle

Profiling in Unreal Insights shows hundreds of FMODAudioComponents (200–500) alive simultaneously, each costing a few microseconds, which accumulate into significant frame-wide CPU time.

FMOD itself does not appear to be performing heavy DSP work — most of these event instances **appear**  **to be** virtualized voices, but their corresponding Unreal FMODAudioComponents remain attached, active and continue to tick indefinitely.

_Unreal Insights consistently shows:_

_FMODAudioComponent_

_Count: ~200–500_

_Incl: ~1.2–2.0 ms_

_Excl: ~1.0–1.8 ms_

_Even when no audible FMOD events are expected._

### _ **Severe spikes in UpdateComponentToWorld** _

_FMODAudioComponent instances appear under:_

_UpdateChildTransforms → UpdateComponentToWorld → FMODAudioComponent_

_ **Components persist even if event audio is silent or virtualized** _

_FMOD DSP time is extremely low → expected if voices are virtualized.  
However, their Unreal components remain alive and continue ticking._

### _ **Occurs across many actor types** _

_Not isolated to a single weapon or enemy type.  
Seen in:_

- _Sounds called by Gameplay Cues_

- _Sounds called directly on code._

- _Apparently, with sounds called by the “UFMODBlueprintStatics::PlayEventAttached” function_

# **Environment Details**

- Game uses **object pooling** for most enemies.

- Many sounds use PlayEventAtLocation or PlayEventAttached **(in all cases we keep the bAutoDestroy bool as “true”.)**

- Some events have **long tails** , reverb zones, or multi-instrument layering

- Some weapons fire rapidly (machine gun), causing many simultaneous one-shots

- Voice stealing/polyphony limits enabled for certain events

# **Observed Behavior**

1. **Each FMOD event instance spawns a new FMODAudioComponent** (expected)

2. Many of these events are virtualized by FMOD

3. The underlying FMODAudioComponent persists:

4. Over time, the number of active FMODAudioComponents grows:

5. Unreal continues to run transform updates and tick logic for **every** FMODAudioComponent

6. CPU cost scales linearly with number of components

7. Eventually, frame times spike significantly on Oculus Quest

# **Hypotheses (What we suspect might be happening)**

**Hypothesis A: FMOD virtualized voices do not destroy their Unreal components**

FMOD virtualizes voices when polyphony limits are reached, or when volume falls below audibility thresholds.  
However, the Unreal UFMODAudioComponent persists and continues ticking even if:

- Audio has been virtualized

- No DSP processing is occurring

- The event is effectively silent

**Hypothesis B: PlayEventAtLocation and PlayEventAttached create short-lived components with long auto-flush times**

If the event contains:

- Long reverb tails

- Sustain points

- Loop regions

- Multi-instrument delays

- Attenuation curves with slow fade-outs

…then FMOD keeps event instances alive longer than expected.  
Even if the sound is inaudible, the Unreal component may persist until FMOD fully releases it.

**Hypothesis C: Interaction with Unreal actor pooling**

When pooled actors “die”:

- They are **not destroyed** , so EndPlay() is not executed

- Any attached FMOD event instances are not stopped

- When actors respawn, new audio components are added on top of old ones

- Over time this produces a \*\*component leak  
\*\*

**Hypothesis D: Virtualized voices re-activate or never fully stop**

Because FMOD tries to preserve event state for unvirtualization, it may keep instances alive longer than expected, and Unreal components don’t auto-destroy.

Said that maybe you can give us some answers fo teh following questions:

1. **Clarification on the expected lifecycle of virtualized event instances in Unreal**

2. **Recommended way to ensure FMODAudioComponents are fully released**

3. **Whether FMOD provides callbacks for virtualization state changes**  
e.g. _“OnVirtualize”, “OnUnvirtualize”_  
so we can destroy components earlier.

4. **Guidance on pooling compatibility**

5. **Verification that FMODAudioComponent ticking thousands of virtualized instances is intended**  
Or whether this could be a bug.

We very much appreciate your help!

---

<div class="post-metadata">

**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:** [December 1, 2025, 11:17pm UTC](https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715/2 "2025-12-01T23:17:19Z")

</div>

Hi,

Thank you for bringing this to our attention and thank you for all the detail you provided.

1. _ **Clarification on the expected lifecycle of virtualized event instances in Unreal** _

2. _ **Recommended way to ensure FMODAudioComponents are fully released** _

3. _ **Whether FMOD provides callbacks for virtualization state changes**  
e.g. “OnVirtualize”, “OnUnvirtualize”  
so we can destroy components earlier_

4. _ **Guidance on pooling compatibility** _

5. _ **Verification that FMODAudioComponent ticking thousands of virtualized instances is intended** _

Thank you again for all the detail you provided,

---

<div class="post-metadata">

**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:** [December 2, 2025, 1:30am UTC](https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715/3 "2025-12-02T01:30:09Z")

</div>

I see you are using **bAutoDestroy** are you also using `bStopWhenAttachedToDestroyed`?  
[Unreal Integration | Blueprint Reference Common - Play Event Attached](https://fmod.com/docs/2.03/unreal/blueprint-reference-common.html#play-event-attached)

---

<div class="post-metadata">

**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:** [December 2, 2025, 10:14pm UTC](https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715/4 "2025-12-02T22:14:18Z")

</div>

I have updated my original response with some more information.

---

<div class="post-metadata">

**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:** [December 10, 2025, 12:32am UTC](https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715/5 "2025-12-10T00:32:36Z")

</div>

Hi,

Just checking in if you were able to find a solution or if there was anything else we could assist with?

---

<div class="post-metadata">

**Author:** ![Dzambrano](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dzambrano](https://qa.fmod.com/u/Dzambrano)\
**Post date:** [December 11, 2025, 7:32pm UTC](https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715/6 "2025-12-11T19:32:12Z")

</div>

Hello Connor,

Sorry for the late response, and thanks for the update!

We have been working on detecting the source for these issues.

One of the problems we had it was that some FMOD events were set as **Persistent** inside our fmod project, this resulted on them not being destroyed after triggered.

However we countinue to experience the problem in other events that are not set as persistent.

We are currently investigating and will keep you informed via updates on this thread!

---

<div class="post-metadata">

**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:** [December 11, 2025, 10:47pm UTC](https://qa.fmod.com/t/unreal-engine-fmodaudiocomponent-accumulation-performance/23715/7 "2025-12-11T22:47:58Z")

</div>

That is interesting, thank you for the info. Keen to hear your updates!
