Yep, not surprised.
So this is the root issue – something about setting individual volumes of sources to 0.0 is causing the problem. By muting the entire application output it bypasses the problem but doesn’t quite fix it.
Like I said, I also think it may be a timing issue.
The following changes seems to mitigate the issue UT, but not entirely. I can still barely hear tiny pops, but this might be worth trying to see if it helps.
In AudioMixerSourceManager.h, change the SourceCommandQueue TQueue into the following:
And then in AudioMixerSourceManager.cpp, in the update function (which is called from audio thread).
Then in the AudioMixerThreadCommand function and the PimpCommandQueue function, do the following changes:
The theory of the change is that there are some corner cases where commands can be enqueued from the audio thread (which set params on playing sources) while the command queue is getting pumped, so there can be individual audio mixer render frames where sources don’t have the proper values set, which causes discontinuities. This change basically creates 2 different command queues which swap out with each other after the render thread has consumed the previous audio render thread command queue.
As I said, testing with this change (and not the master attenuation application), I can hear a reduction in the issue, but I’m still hearing very quiet pops. I’m about to dig deep in this and add a bunch of custom instrumentation to validate expected state when the application is muted by FApp::GetVolumeMultiplier().