Possible solution: x64 audio bug

[Suspiria]

After two months since its discovery, my latest fix-candidate is now LIVE.
This will be our third attempt since the beginning of 2019. (I can't speak for the developers before me)

To anyone reading this:

Please report if you still encounter this sound crash on map change a.k.a. "the sound bug".
Also, kindly refrain from reporting issues with sound here that do not occur on map change. (please create a new topic for that)

Thank you!! 

And thanks everyone #DEV and #TestTeam for all the support and testing.
Wouldn't have made it to this #3 without you.

Edited May 2, 2022 by Suspiria

[Suspiria]

By the way, the second part of this candidate would be to switch to WorldInfo.ForceGarbageCollection(TRUE).
I didn't include it in the original post, but it's, like, the other half of this equation and may be more effective.

So far I've heard of two people who claim they still encountered this sound bug within the last two weeks.
Once there is a third report, I think it may be a good time to consider switching to full purge in the next patch.

Spoiler

Like, adapting in PlayerController / Rx_Controller:

Old:
/** forces GC at the end of the tick on the client */
reliable client event ClientForceGarbageCollection()
{
    WorldInfo.ForceGarbageCollection();
}

New:
/** forces GC at the end of the tick on the client */
reliable client event ClientForceGarbageCollection(optional bool FullPurge = FALSE)
{
    WorldInfo.ForceGarbageCollection(FullPurge);
}

And then not forgetting (!) to also change the call from ProcessClientTravel in GameInfo / Rx_Game:
from P.ForceGarbageCollection() to P.ForceGarbageCollection(TRUE).

Edited May 3, 2022 by Suspiria

[Suspiria]

Ooh sweet jesus, I may have found the true culprit on the deeper level, within code.

Look at this!

So inside Rx_HUD.uc we set WorldInfo.MusicComp to JukeBox.MusicComp during PostBeginPlay.
We then set the WorldInfo.MusicComp.OnAudioFinished delegate to MusicPlayerOnAudioFinished so that it runs the rest of the playlist.

So far so good.

So, Rx_HUD also implements a Destroyed() event which is called during mapchange.
Destroyed() calls ResetToDefaults() which resets all properties.

But delegates are not properties.
So the delegate is still set.

And - here comes the sound bug - Rx_JukeBox's bStopped has not been set to true.
Because Rx_HUD's Destroyed function is calling Stop() directly on MusicComp instead of on Rx_JukeBox.

Guess what happens after we call Stop while the bAutoDestroy flag is set??

...

I highly recommend we change this line within Rx_HUD's Destroyed() event:

        JukeBox.MusicComp.Stop();

to this:

        JukeBox.Stop();

ASAP

Spoiler

Look, I'll explain.

During travel a destroy function is called inside the AudioComponent.
This will neately cleanup the audio first, and then mark this component for kill by GC.

So, it *was* the intention to design UE3 in such a way that you can't accidentally deallocate a live audio stream before first cleaning it up through a destroy function.

Sound bug arises because bAutoDestroy does not actually call a destroy function under the hood.
Rather it directly marks the component for kill by GC without cleaning up through destroy first.

IF there is no audio playing, which they have attempted to make sure through syntax, this is not a problem.
bAutoDestroy has been designed in such a way that it is only applied during Stop or ResetToDefaults. (the latter already calls Stop internally)

But Epic forgot one thing.. Delegates.
Delegates that might just start Playing a new audio stream.

So here we had Stopped the MusicComp and had it marked for kill with bAutoDestroy.
But then the OnAudioFinished delegate called into our MusicPlayerOnAudioFinished and started a new Play because we have failed to set bStopped to true.

Guess what happens when GC now comes around for its periodic sweep, midtravel after all Actors were destructed??
Right! It's totally going to deallocate a live audio stream.

And if I were an audio subsystem or XAudio2 interface, I'd go kaboom at this point.
Would you not?

@Handepsilon @SonnyX @NodSaibot

Edited May 13, 2022 by Suspiria

[roweboat]

to be honest, this is all Greek to me, but if it fixes the problems and more people want to play the game. awesome =D

[Suspiria]

1 hour ago, roweboat said:

to be honest, this is all Greek to me, but if it fixes the problems and more people want to play the game. awesome =D

Have not fixed anything yet so I'm still eating some humble pie here.
But I fully intend for this bug to go down before Firestorm.

I've learned in life that sometimes you just have to stick to your guns and eventually you'll get it.
Albert Einstein said: "It's not that I'm so smart, it's just that I stay with problems longer." and I guess we're gonna find out if that's true.

Edited May 13, 2022 by Suspiria

[Suspiria]

17 hours ago, roweboat said:

to be honest, this is all Greek to me, but if it fixes the problems and more people want to play the game. awesome =D

Also, the deeply technical explanations were really not ment for you, haha.
They were ment for other developers.

Many of which have little experience with systems level programming. (C++, Rust, Assembly)
I wouldn't be surprised if only SonnyX and I are comfortable working with it.

I use this thread to document the bug hunt.
For education and curiosity's sake, but also in case of failure so that the next could pick up.

But I absolutely appreciate your appreciation of my efforts and your ongoing eyes-and-ears support.
To me this is fuel for the hunt. ^^

[Handepsilon]

So, late update, but Rx_HUD since 20th of May was already changed to do so. The soundbug still occurs

Also, to note : This happens a LOT in SDK too, and at times you don't even need to playtest the map you're playing. The sound just pops randomly