Messages

16

Preview Build Discussion / Re: High CPU usage

« on: September 23, 2026, 04:34:57 PM »

The two threads showing the high cpu are the input & output processing threads the dsp_wc plug-in uses as I suspected from the earlier screenshots. As it uses two threads so it can take the audio from what's playing & then collates it for the stream encoders to then do their thing when they're ready for it which if not done on threads would basically mean it blocks things & that ends up causing more problems. The other thread shown relates to the ui (i.e. doing the updating of the streaming prefs page) & few other things with the stream handling

I've now had a look at the dump file (I've removed the download link to it) & I think I see what is most likely causing the problem for you with it relating to how title updates are done which over time wasn't correctly cleaning up some internal connection handling making it spin over things that have long since been removed (aka wasting cpu time). There's a change now in place for the next build which I'm hoping will improve the situation though I'm still not 100% that it is the definite reason behind the problem but will have to see from more testing.

17

General Discussion / Re: WACUP 1.99.54.24960 crash

« on: September 21, 2026, 05:43:44 PM »

It did in the end with it just being a mislabelled mp3 file so is something I need to consider how I'm going to handle such files to avoid them going to the directshow filters & the potential problems that might occur from that vs passing it directly to the mp3 which should behave ok.

18

Preview Build Discussion / Re: Online radio streams not playing in 1.99.54.24960 (worked before)

« on: September 19, 2026, 05:09:08 PM »

I've found an intermittent issue which can prevent shoutcast based urls from being correctly processed if triggered from within the internet radio view which could then cause in_url to leave things in a somewhat stuck state since it doesn't know how to handle the m3u based playlist contents. That's the nearest I can get to what was being initially described (not that I could replicate with those example playlists).

There's also so many old radionomy & listen.shoutcast stream urls being provided despite none of them working for many years as of this reply which you only know that's what it is when going from the internet radio view to the main playlist (with the fixed handling in my dev build) which were meant to be flagged as invalid to play. That's now been added into in_url since it was previously an x86 build patch when using in_mp3 for streaming playback but as that's not used for it now I hadn't moved it from the core into in_url because I forgot about it. I don't know if this is behind the other comment of so many not working or not...

19

Preview Build Discussion / Re: [Bug] WACUP startup hangs with AudioBurst 2.22 / out_burst.dll

« on: September 19, 2026, 01:45:33 PM »

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.

20

Preview Build Discussion / Re: [Bug] WACUP startup hangs with AudioBurst 2.22 / out_burst.dll

« on: September 18, 2026, 11:38:36 PM »

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.

21

General Discussion / Re: WACUP 1.99.54.24960 crash

« on: September 18, 2026, 09:52:15 PM »

Alternatively rename the file to be MP3 & that should also behave instead of what I'd suggested above. As I've had another look at the file's actual contents as I was considering doing a non-directshow mpeg decoder for what I thought it was & it's afaict just a mis-labelled mp3 file & not an actual mpeg file. That's something I should've checked instead of just trusting the extension vs what plug-ins it was going through.

22

General Discussion / Re: WACUP 1.99.54.24960 crash

« on: September 17, 2026, 09:27:30 AM »

I've had a quick test (have removed the attachment now I've got the file) & it seems to be playing ok both with & without the post-release patches made to the 24960 build (which had another update yesterday the 16th). My guess now is it might be related to the directshow filters being used as I can't find anything obviously wrong with the file when using lav 0.81 & 0.83 (hadn't seen it had been updated).

Otherwise you're possibly hitting a core handling bug that might be corrupting things within the process which is an intermittent problem & could also explain the issues getting it to work with procdump & is something that's more likely to affect the x64 build based on the crash reports that I have seen.

The best fix if you still want to play it especially when everything else is mp3 would be to use something like ffmpeg to extract the mp3 audio in the mpeg file into a normal mp3 file without the extra overhead. That should then play fine & it avoids the directshow handling along with it avoid any reconversion with audio data loss since its just taking mp3 data out of the mpeg container.

23

Preview Build Discussion / Re: High CPU usage

« on: September 16, 2026, 06:42:25 PM »

Were you able to get any dump files from the process when in that state? As the top 2 are the most likely input & output threads the plug-in uses but without a couple of dump files it's hard to tell why they're doing what they are. Also are you keeping the preference window open throughout all of this?

24

Preview Build Discussion / Re: Online radio streams not playing in 1.99.54.24960 (worked before)

« on: September 16, 2026, 06:36:19 PM »

I don't need the snarky reply ok as I have tried a load of stations & they all played ok for me when using the post-release in_url that I provided when Win11 wasn't blocking it due to (not so) Smart App Control. That is why I asked for specific examples since I can't replicate & for all I know they could be geo-blocked for you but not for others which is something I've no control over. I'm not going to just manually test 100k entries when specific examples that you / others are saying aren't working would be a better use of my time to test out specifically.

25

Skins / Re: Winamp 2.0 to 2.90 beta base skin

« on: September 16, 2026, 06:30:09 PM »

Attach screenshots to the posts & not linking out to services like imgur that are geo-blocked for others (like me).

Also why not just extract the files from 2.81 (unless I'm missing the point of this which is likely when I can't see the screenshots) ?

26

General Discussion / Re: WACUP 1.99.54.24960 crash

« on: September 16, 2026, 06:25:32 PM »

Would it be useful to provide that file here for testing purposes or is this expected behavior?

It would be as mpeg isn't something I've done much testing with & just rely on the directshow decoder to handle it so there's likely something off with how that is done.

I still don't get what is going on for the uninstall to not remove things as the actions should be doing that since they're just put in %appdata%\wacup assuming the default install location (or within 'settings' with portable installs). The only registry key I actively set is related to the uninstaller though I've seen the OS create other things depending on some of the features being used (or when manually doing open with).

27

Preview Build Discussion / Re: CD related feedback

« on: September 05, 2026, 09:35:05 PM »

I've not actively tested cd playback nor the views in a while so it's very likely from other core changes made since I did that things may have regressed / broken. Problems with artwork was also reported but I've still to get a drive hooked back up in my machine to do any testing of the handling.

As for comparing to 5.666, none of the cd or media library handling relates to it & hasn't used any 5.666 plug-ins to do it for long time now (since the x64 build appeared) so problems with any of this are all down to my code alone.

The enter / double-click handling has some control options on the media library root prefs page so that might get it to how you need as I can't remember what I set the default to be (there's things that I default differently compared to what winamp did as that's what I prefer most of the time).

28

Preview Build Discussion / Re: Online radio streams not playing in 1.99.54.24960 (worked before)

« on: September 05, 2026, 06:18:37 PM »

The only thing I've been able to replicate is that some icecast urls are being provided as 'http' but they're only going to respond to a 'https' connection & I've provided that as a post-release update which better deals with that situation (though the icecast instance providing the wrong url despite accessing it directly over an https connection is a bug with icecast imho).

I still cannot replicate any of the provided urls failing to play when in_url is present be it on Win10 or Win11 (which is where I happened upon by chance the 'broken' icecast url). Without clarification of what the status of in_url in the install is (which I ask for a reason to try to save wasting more of everyone's time), there's nothing else I can do & won't be for at least a week (maybe more) due to irl commitments.

29

Preview Build Discussion / Re: Online radio streams not playing in 1.99.54.24960 (worked before)

« on: September 05, 2026, 02:07:07 PM »

wd9895: The station list is updated daily against what I'm able to obtain from a number of sources so unless they're all messing up then that shouldn't be the problem. Examples would be helpful of ones that aren't behaving so I can inspect them.

vikingt: With what's shown it really shouldn't be trying to use the directshow decoder for url playback & would explain why nothing is happening. You need to check that wacup's in_url plug-in is present & enabled & loaded which can be done by going to preferences -> plug-ins -> input -> look in the list for in_url / streaming url processor. If it's not there then you'll need to re-run the installer & hopefully that should correct what is most likely the OS / 'smart app control' (since you've mentioned Win11) messing around with dll loading when there's no reason for it to do so.

30

General Discussion / Re: ver 1.99.54.24960 modern skin MAKI issue

« on: September 05, 2026, 10:43:12 AM »

I've got a simplish fix for you so the skin can work with 24960 by extracting the skin into a 'Quadelic' folder (a .wal file is just a .zip archive) within the wacup skins folder, then open the 'xml\configuration.xml' file within the 'Quadelic' folder & change the <elements/> to be </elements> & save it. Then select the folder extracted version of the skin (it should show with a folder icon next to its name in the skins menu) & that should then load correctly.


The problem is the / in the end elements part is invalid & what I now use for xml parsing doesn't like it but it's also possible that what had been used in earlier builds has been tightening up xml validation so might be why you had to go back a few builds to get it to work again (I've not tried the older builds to see what they're doing but it's a reasonable assumption with the changes that libexpat have kept making & which led me to want to drop it over all of it's security related churn). I still need to code in something that can handle this problem since it'll be expected for such skins to still be able to be loaded though imho the skin should never have been able to be loaded due to the error in the xml but that's another thing against libexpat being a lax parser.