While level streaming, the game thread would get stuck during the ProcessTasksUntilIdle phase.
After some investigation, the issue seems to be that a Delegate named HandleAction may be called again during postload which is causing the hangup.
FAkBlueprintDelegateEventCallbackPackage::HandleAction
if (FUObjectThreadContext::Get().IsRoutingPostLoad)
{
UE_LOG(LogAkAudio, Verbose, TEXT("FAkBlueprintDelegateEventCallbackPackage::HandleAction: Delaying Blueprint execution because IsRoutingPostLoad."));
return EWwiseDeferredAsyncResult::KeepRunning;
}
In order to avoid this, we have ended up disabling this callback.
{Object= (Name=RGIAkMusicSubsystem_0, InternalFlags=ReachabilityFlag0), FunctionName=OnMusicCallback}
Was posting to see why this setup may be causing this callback to fire twice and cause a hangup. Possibly a bug or was there something wrong with how it was created and setup.
[Attachment Removed]
A bit more context:
This was showing up as a soft-lock in Texture2D PostLoad when combined with WWise, but it’s not clear if this is a WWise or UE problem.
The issue is this:
- UTexture::PostLoad() calls FlushRenderingCommands() which waits on FFrameEndSync::FRenderThreadFence
- This calls FNamedTaskThread::ProcessTasksUntilIdle(true) which waits until the game thread task queue is empty
- Meanwhile WWise is executing tasks which cannot run during PostLoad.
- It handles this by checking FUObjectThreadContext::IsRoutingPostLoad(), and then skipping the task (early out) and immediately resubmitting it
- This WWise abort/resumbit loop prevents the FrameEndSync from ever completing
Is WWise breaking the rules here by aborting and resubmitting those tasks? If so, it’s not clear what they should be doing instead, assuming their tasks really cannot run in PostLoad.
[Attachment Removed]
Hello, apologies for the delayed response on our end. We are working on responding to EPS requests more systematically so that this doesn’t happen again. I’m sorry that this one dropped through the cracks.
I encourage you to reach out to Wwise about this one since it looks like an issue in their code. The abort/resubmit loop certainly could cause a hang and they likely need to find a way to defer those calls to a later time. Without looking at their code myself, I’m mostly guessing at the what a solution would be, but there are a few ways they could handle these task issues. They could fix it by storing those undoable tasks in a deferred task queue to drain on next tick. Or they could utilize a tick group or tick function which would allow better control over when a task is executed within the Game Thread Tick. Eitherway, it will have to be a fix on their end. Though please let me know if they say it’s a UE problem and I can see if I can reach out to them directly.
Best,
Phil P.
[Attachment Removed]