Audiokinetic's Community Q&A is the forum where users can ask and answer questions within the Wwise and Strata communities. If you would like to get an answer from Audiokinetic's Technical support team, make sure you use the Support Tickets page.

[Has Workaround] Wwise 2019.2.7250.1621 Unreal Pkg Crash if AkModule is loaded in asynch load due to FAkAudioStyle

0 votes

Hi!

So I guess this is partly an FYI. We are on Unreal 4.23 and recently upgraded to WWise 2019.2.7250.1621 from 2019.1.4.7065.1430.

One thing that has changed between these two versions is that FAkAudioStyle::Initialize() is now run from AkAudioModule::StartupModule().

In our case this causes a crash due to the following flow:

  • During game startup an asynchronous load of some pre-loaded game assets triggers.
  • Game asset references Ak assets, forcing a load of the Ak Module.
  • AkModule::StartupModule() runs FAkAudioStyle::Initialize() which in turns run LoadAkTexture().
  • LoadAkTexture() attempts to run an asynchronous load of the texture.
  • Unreal asserts because it does not allow nested asynchronous loads.

As far as I can see FAkAudioStyle only sets up Editor UI, so I do not se why it is run outside #if WITH_EDITOR? 

As a work around we have moved it inside the define and it seems to work as expected. 

Do you have any information on why it has been set up like this, and if there could be any issues with our workaround?

Thankful for any info,
Anders

asked Apr 24, 2020 in General Discussion by Anders H. (110 points)
This was our solution as well. If FAkAudioStyle::Initialize() in FAkAudioModule::StartupModule() isn't wrapped by WITH_EDITOR, you will get packaging failures on shipping builds as well.

Also found this async issue if you try to load an actor with references to audio events before FAkAudioDevice::Get() is called for the first time. This happens with using the new no banks feature.
Ok, thanks for the validation and heads-up if we run in to the other issues! :)
Yeah, now we're running into the other issue as well. How did you fix that one? Force a call to FAkAudioDevice::Get() somewhere? If yes, where?

Thanks in advance!
In our case the offending actor was being created in a another plugin's constructor. That actor prompted the sound to load before FAkAudioDevice::Get() was first called. So I delayed the initialization of the actor based on UE4's actor lifecycle documentation.
Ok, thanks! I think we seem to have a more tricky situation, digging into it as we speak.

Please sign-in or register to answer this question.

...