FMODAudioComponent Ticking


So as part of optimising our game I dug around in FMOD wondering why so many components were ticking. The component tick is set to false after playback is stopped but this isn’t true on load. I am unsure if this is something to do with the way UE4 handles components and keeping them up to date but I found that the tick is never set to false if the component starts inactive (bAutoActivate = false).

The tick function in the component currently looks like this:

Super::TickComponent(DeltaTime, TickType, ThisTickFunction);

if (bIsActive)
	//some lovely FMOD code

I modified this by adding an else to the end of the if to turn off the component tick. The tick function after modification looks like this:

Super::TickComponent(DeltaTime, TickType, ThisTickFunction);

if (bIsActive)
	//some lovely FMOD code

I am unsure if this will break anything with FMOD or cause any issues with the sounds maybe being out of place for the first frame of playback starting but I haven’t noticed any issues. I have asked more audio capable coworkers to have a listen and see if they notice anything.

For us this reduced the number of ticks in our main level from over 1100 to about 300. There were a lot of components in actors that were ticking despite not having Auto Activate on and not being told to play.

Again I am unsure if this would break anything since I know some UE4 components like to tick all the time just to maintain correct positioning. I will look into forcing the component to perform necessary updates at the start of playback if it doesn’t already.

Could someone shed some light on whether this would cause issues and would steps could be taken to resolve them?


As it happens, I’ve been looking at this myself for Earthfall. The problem is that void UFMODAudioComponent::Activate(bool bReset) and void UFMODAudioComponent::Deactivate()
Fail to call Super::Activate() and Super::Deactivate(), which is where ticking gets turned on and off by default. This means that inactive FModComponents continue to tick, cluttering up the tick lists. The ::TickComponent function does check bIsActive and skip a lot of the work if it’s not, but it shouldn’t be ticking at all. I’ve added calls to Super in our code and removed a zillion or so tickfunctions and the associated perf hit as a result.

Hey FMod! Do you know if there’s any problem with doing that?


As Rick mentioned, it is the Super::Activate() and Super::Deactivate() that control when the ticking is turned on and off. As far as I can tell from testing it doesn’t look like anything is hurt by using that method.

I have added a task to add this to the integration and will keep testing in the meantime just in case it does not agree with something else.


I’ve run into the same problem: lots of silent FMODAudioComponents spending time ticking as soon as the game starts.

In my experience, there is no problem with UFMODAudioComponent::Activate() and Deactivate(). They do not call the Super:: method because they completely override the base class behavior, calling methods Play() and Stop() which in turn call SetComponentTickEnabled().

However, this line in the constructor:
PrimaryComponentTick.bCanEverTick = true;

should be followed by this one:
PrimaryComponentTick.bStartWithTickEnabled = false;

Without it, the component starts with ticking enabled.


Thanks Julien, we will look into this further.