UE 5.4 crash in Audio::ArrayDeinterleave

Development Audio
, ,
1

Dear UDN Support Team,

We are having an audio-related crash on boot in our 5.4.4-powered title. It seems to randomly occur on various PCs an we’re not able to understand if there’s any pattern to it. I’m attaching a log && dxdiag from the PC that seems to be able to get this crash the most times. Please advise.

Thank you!

--

Kind regards,

Alex

2

Steps to Reproduce

3

Hi Alex,

Could you try grabbing CL# 34475871 and see if that resolves the crash? That should be a one-line change, and it fixed a similar crash that we encountered in the City Sample project with the same callstack. Let me know if you still see issues with that fix.

Best,

Cody

4

Hi Cody,

Thank you so much! After the integration, the crash seem to be changed to have the following stack:

PredecessorClient_Win64_Test!ArrayMultiplyByConstant_avx2

PredecessorClient_Win64_Test!ArrayMultiplyByConstant

PredecessorClient_Win64_Test!Audio::ArrayMultiplyByConstant D:/Workspace/Engine/Source/Runtime/SignalProcessing/Private/FloatArrayMath.cpp(921)

PredecessorClient_Win64_Test!Audio::FDynamicsProcessor::ProcessAudioDeinterleaveInternal D:/Workspace/Engine/Source/Runtime/SignalProcessing/Private/DynamicsProcessor.cpp(449)

PredecessorClient_Win64_Test!Audio::FDynamicsProcessor::ProcessAudio D:/Workspace/Engine/Source/Runtime/SignalProcessing/Private/DynamicsProcessor.cpp(367)

PredecessorClient_Win64_Test!FSubmixEffectDynamicsProcessor::OnProcessAudio D:/Workspace/Engine/Source/Runtime/AudioMixer/Private/Effects/AudioMixerSubmixEffectDynamicsProcessor.cpp(305)

PredecessorClient_Win64_Test!FSoundEffectSubmix::ProcessAudio D:/Workspace/Engine/Source/Runtime/Engine/Private/SoundEffectSubmix.cpp(23)

PredecessorClient_Win64_Test!Audio::FMixerSubmix::GenerateEffectChainAudio D:/Workspace/Engine/Source/Runtime/AudioMixer/Private/AudioMixerSubmix.cpp(1688)

PredecessorClient_Win64_Test!Audio::FMixerSubmix::ProcessAudio D:/Workspace/Engine/Source/Runtime/AudioMixer/Private/AudioMixerSubmix.cpp(1415)

PredecessorClient_Win64_Test!Audio::FMixerSubmix::ProcessAudio D:/Workspace/Engine/Source/Runtime/AudioMixer/Private/AudioMixerSubmix.cpp(1303)

PredecessorClient_Win64_Test!Audio::FMixerDevice::OnProcessAudioStream D:/Workspace/Engine/Source/Runtime/AudioMixer/Private/AudioMixerDevice.cpp(932)

PredecessorClient_Win64_Test!Audio::FOutputBuffer::MixNextBuffer D:/Workspace/Engine/Source/Runtime/AudioMixerCore/Private/AudioMixer.cpp(247)

PredecessorClient_Win64_Test!Audio::IAudioMixerPlatformInterface::RunInternal D:/Workspace/Engine/Source/Runtime/AudioMixerCore/Private/AudioMixer.cpp(744)

PredecessorClient_Win64_Test!Audio::IAudioMixerPlatformInterface::Run D:/Workspace/Engine/Source/Runtime/AudioMixerCore/Private/AudioMixer.cpp(793)

PredecessorClient_Win64_Test!FRunnableThreadWin::Run D:/Workspace/Engine/Source/Runtime/Core/Private/Windows/WindowsRunnableThread.cpp(149)

PredecessorClient_Win64_Test!FRunnableThreadWin::GuardedRun D:/Workspace/Engine/Source/Runtime/Core/Private/Windows/WindowsRunnableThread.cpp(79)

kernel32!BaseThreadInitThunk

ntdll!RtlUserThreadStart

We’ve also seem to find a reliable repro for this:

  1. Connect a wireless audio device;
  2. Launch the title;
  3. Disconnect or turn off the wireless audio device;
  4. Observe the crash.

Reproes on Shure MV7 and Sony DualShock 4/Dual Sense.

Please advise.

--

Kind regards,

Alex

5

Hi,

There was a similar crash reported on this post with a potential fix (the !bPatchIsValid conditional), though we haven’t confirmed if it resolved the issue. Could you give that a try and let us know if the crash still occurs?

Best,

Cody

6

Hi Cody,

Thank you, I’m happy to try anything. For some reason, I cannot open the link you posted (access missing?)

--

Kind regards,

Alex

7

Ah apologies, I posted the wrong link. Here’s the correct one:

[Content removed]

8

Hi Cody,

Thank you! We get the crash with the same repro and callstack after adding this change. Please advise.

--

Kind regards,

Alex

9

I think I found a work-around for the crash now.

So the repro case is:

  • Have an default audio device with 4 key channels, (FrontLeft, FrontRight, BackLeft, BackRight) for example.. then change to an audio device with less channels, say 2.

If we change the check in ProcessAudio() to an if statement like suggested in the other post, we get a constant sound, as no buffers are ever update I guess?

However, if we just change the number of key channels, it seems to work. Do you think this solution is okay or do you foresee any problems with it?[Image Removed] Kind regards,

Gregor

10

That seems sane at first glance. I have a message out to some of our devs more familiar to confirm.

The fix you integrated initially (this change) was a fix for the exact same repro you’re describing, and we haven’t seen the issue anymore in 5.5.

That file hasn’t changed much over the last few years so it may be worth diffing it between 5.5 and 5.5.4 to see if there are any other one-line changes you’re missing.