[Bug] WACUP startup hangs with AudioBurst 2.22 / out_burst.dll

[RAGEdemon]

I'm seeing a repeatable startup hang with the old AudioBurst 2.22 output plugin (`out_burst.dll`).

### Setup

* WACUP x86
* Current public preview build
* AudioBurst 2.22
* Windows 11
* AudioBurst is being used only for its audio processing. All of its analyser / visual / display functionality is disabled.

### Symptoms

With AudioBurst enabled, WACUP frequently hangs for around 10 seconds during startup before the playlist finishes populating. Occasionally it appears to remain hung indefinitely.

Once startup completes and the playlist appears, everything works normally and playback through AudioBurst is completely stable.

If I disable AudioBurst, WACUP starts essentially instantly every time.

There's also a strange but highly repeatable timing effect: if WACUP appears hung during startup and I put its window behind a maximised Firefox window, startup then succeeds roughly 90% of the time.

AudioBurst itself was working normally with my WACUP installation in the past, so this seems to be a relatively recent compatibility/timing issue.

### ProcDump results

I captured two independent full memory dumps using:

`procdump64.exe -ma -h -w wacup.exe`

Both dumps show essentially the same thing.

In both cases the WACUP main/UI thread is inside:

`NtUserMsgWaitForMultipleObjectsEx`

and is waiting indefinitely on a single thread handle.

In dump 1:

* waited-on handle: `0x334`
* handle type: Thread
* target TID: `0x11B0` / 4528
* that thread is executing inside `audioburst.dll`

In dump 2:

* waited-on handle: `0x348`
* handle type: Thread
* target TID: `0x48CC` / 18636
* that thread is again executing inside `audioburst.dll`

In both dumps, the AudioBurst-related thread appears to have been created from the same location:

`winamp.dll + 0xB08F0`

The captured execution locations inside AudioBurst were approximately:

`audioburst.dll + 0x9AA8E7`

and

`audioburst.dll + 0x9A9B1E`

So two separate hangs seem to show the same sequence: WACUP creates a worker/init thread, that thread enters AudioBurst, and the main thread waits for it to finish.

The two locations captured inside `audioburst.dll` are also very close to one another, despite these being independent startup attempts.

This makes me wonder whether WACUP is synchronously waiting for the legacy output plugin's initialization thread and AudioBurst is hitting some old timing/message-pump issue during startup.

The odd Firefox/occlusion behaviour also suggests that changing GUI scheduling/message timing is somehow allowing the initialization to complete.

### Dumps

I have both full ProcDump captures available and can provide them if useful.

Each dump is approximately 286 MB uncompressed.

Happy to run another build, collect additional dumps, or test any instrumentation/change that would help narrow it down.

[dro]

From a not so quick re-test of the plug-in (I don't actively use it though I know some do & I had a copy of it already from some time back) it's not what I'd deem to be a well behaved plug-in even if it does then seem to play ok. That's likely related to it using a compressed audioburst.dll (~9MB on disk but seems to de-compress to ~12MB as a best guess) which depending on how the OS is scanning things (e.g. smart app control) could be behind some of the slowness along with it's anti-piracy aspects built into it.

On Win10 (it's now too late today for me to be messing with Win11 VMs though I'll have to look into it) I see up to 3 seconds of it appearing to block the main ui thread. I can also see it adding a load of time to the initial phase of trying to process out_*.dll which isn't there when the dll is disabled via the preferences which afaict aligns with the self-extraction it seems to do but I can't be certain as it throws an error when I'm doing anything under a debugger as soon as the plug-ins output module is attempted to be accessed (which would relate to it trying to get & load the audioburst.dll). For comparison, that up to 3 seconds delay is the same I see with a winamp 2.9x test install.

There's also it's desire to create a thread for at least every cpu core which might've made things more responsive when dual core setups weren't common but the 16 threads it's creating with my 3700X based setup cannot be helping matters. Plus based on your specs where I'd assume it's likely trying to spin up 24 threads (that's more than wacup overall tends to use) it's just not doing what imho is reasonable.


From my side I just attempt to load the plug-in dll & it then does whatever it's going to do. The only place where things might be waiting is if doing immediate playback on start-up & from what I'm seeing out_burst / audioburst.dll is blocking the main ui thread which needs to be available for things to commence playback properly (that's an aspect of winamp plug-in compatibility which I've got to follow & hasn't been changed with how I handle that side of things in a very long time once I got playback compatibility seemingly correct for what's required).

I've also noticed that it's still doing a bunch of it's initialisation even if it's not the active output plug-in to be used where I see it take a similar time for the speakers ui elements it wants to show to appear with that taking about the same time to happen in vs it being the active output plug-in & resuming playback on loading.

Overall at the moment I don't see it being something I'm necessarily doing wrong & it's the plug-in with it's poor assumptions & trying to avoid piracy that are most likely behind the problems that are happening with it. I still need to see what some older wacup preview builds are doing with it (since you've said it was ok at some point in the past though I'm also aware that Win11 has also changed a fair bit just based on how my VM experience of it has changed over even the past year) but I doubt it'll show anything obviously different vs my re-test. So I don't think there's any point having the dmp files (which do tend to compress down well) as I appear to see the same delay but just not as bad as you're having nor is there anything from the build that can be toggled to aid in debugging it further as things currently are.

[dro]

I've done a bit more on this & the only thing I can change is how I deal with loading / unloading of the output plug-ins. As out_burst can trigger an unloading crash if there's no playback happening after going to the output plug-in preference page & then closing it. This is because I try to avoid the output plug-ins being loaded until they're actually needed but out_burst's behaviour doesn't get on well with that.

Under Win11 I cannot replicate the really long delay to get things loading (it's still in the 2-3 second window I'm seeing) so there's likely something else going on that I'm missing. If you can compress & pm a copy of the dmp files then I'll have a look but I don't think there's anything I can really do about it but to just be certain I'll need to have a look at them when I don't seem to be able to get it to occur for me.