I hope everyone had an enjoyable Eurovision filled week (be that watching it or plain avoiding it). This week saw the release of a small update of the Crystal Classic Skins Plug-in to v2.1 which is mainly about reducing it’s load-time overhead.
The optimisations for the plug-in were done by looking at the data collected from the settings file cache (e.g. winamp.ini) that I’ve been on / off working on and finally finished off this week. The point of this cache is to help reduce the number of times that the settings files have to be read (as reading ini files, especially larger ones is relatively slow due to how it works with the OS.
This is why (if I’m remembering correctly) the NSIS project changed their default way of making it’s UI to not involve ini files a few years back. (InstallOptions -> nsDialogs for those interested).
Winamp itself relies quite heavily on these files and so it can have an effect on loading times which is what I wanted to look into with this cache which it does help but is in the range of milliseconds for my SSD based test setup (though there’s a better reduction I’ve found when I’m running Winamp under a debugger with the cache enabled). For non-SSD / restricted resource setups it should be a bit more noticeable depending on the drive and OS caching.
One thing that I hadn’t thought about but have since finished off with this cache work is that it makes it easier to see if a settings value has changed from what was read in when asked to save it back out. By checking if there is an actual change or not, I’m able to now filter out wasteful re-writes of settings (as why re-save what hasn’t changed?) and that has reduced my general Winamp closing time between 0.5 and 1s (depending on the skin being used and overall system load).
In combination with with the library database changes to only re-save if that has seen an actual change, this cache should make a WACUP install a bit more reliable to a plain Winamp install and a bit faster to start / close (there is also a small improvement with skin switching related to this as there’s a number of repeated settings file re-reads during that time).
In addition to the settings cache being finished, I’ve also mostly done a replacement xml reader component (i.e. xml.w5s replacement) which is still based on libexpat (though that may change).
This is because I was intrigued as I’ve used libexpat for other projects for a while so whilst figuring out some other things in my mind. So I thought I’d give it a quick go to see if with the old SDK headers I found I could replicate it easily or not (the only real pain has been making sure that start and end tag matching works so that modern skins will work correctly).
It also means that at a later time I can see if there’s any improvement (i.e. noticeably less time to parse skin files) by swapping the xml parser to a different library which having my own version of the xml reader component to play with now allows.
The other main completed item is adding a copy of libflac to the pack which is based on the “newer” 1.3.1 release. Thankfully what Winamp has been using in the past doesn’t do anything special versus the official libflac release so this was a quick one to sort out and test to make sure FLAC playback, etc still works ok with the in_flac.dll present in Winamp.
Onto other things, I’ll now quickly address a few of the points raised in comments at the end of last week’s post.
The first is that I was mistaken about what I’d heard about the ‘new’ Winamp’s MP3 decoder which will still be an included version and not rely on the OS. Though that still leaves AAC related playback aspects which is an issue if on an older version of Windows or one of the stripped down Windows releases where that support isn’t present. As for encoding support (as AOL had paid a general license for AAC decoding and encoding and a few other things), that appears to be gone with these changes which can probably all be worked around by getting older copies of the plug-ins (as has been done already by some as it doesn’t sound like updating would keep the old ways of doing things) but that somewhat makes things more of a hassle imho to get setup etc (but then other players have had to deal with that previously).
The second is that I’d initially stated that I’d be open to still ensuring things will work on Windows XP (seeing as the Winamp 5.666 release works on it). But I’ve since reviewed my thoughts on the matter and I’ll only be aiming things to work on Windows 7 and newer. So for that I’ve updated the requirements. This comes down to the interest of what OS people want to test on and just making my life easier. So I’ll primarily be developing against Windows 7 and Windows 10 as the targeted OS.
The third is that for the beta testing, either a small forum or a mailing list are the most popular options suggested so far. So i’ll have a look into viable options for either of these to see what’s out there and what fits in with how I’d like to manage them (suggestions on what to look at are welcome).
And finally if people have shown interest to help test things, even if I don’t directly acknowledge it, I am making a note of who has asked to take part just so all is clear on that matter :o)
So until next week’s update have a good week and I’ll now get back to finishing off things I’ve already started on ;o)
-dro
I think it’s wise to concentrate on Win7-10. Not just for the sake of your own sanity (depending on the number of testers and OS’s they are testing on - many reports) but also looking at OS user stats, there seems to be an inverse relation between Win10 (increase) and Win7 (decrease) OS’s while WinXP has for the most part become pretty insignificant (and it isn’t officially support anymore anyways). I think it’s good to focus on maintaining reliability on as many OS’s as possible, but you have to draw the line somewhere and it’s good to focus on the future. It’s where most of the users exist and are headed anyways
Well Win7 and Win10 are what everyone who has shown interest so far have mentioned for helping with testing on. So that was the primary reason to drop XP from testing / support, though if it all still works on XP then I’m not going to intentionally break things as to be honest, I’m unlikely to be using any majorly different API to achieve things from what is already provided from even prior to XP. But definitely from looking at general OS usage levels from other sites and from the basic stats that analytics for this site show, XP just doesn’t seem to be worth it (which is a good thing) but then it’s more likely that any Winamp user still on XP isn’t going to be using a Winamp release that is current (based on the random please make this plug-in work on 2.x requests that still come through).