Week 28

I’m hoping this being a day late in actual posting is ok based on the things that will be covered in this update. So without messing around and in no particular order lets get on with this week’s update :)


The first thing was something that had been running around my head for a while due to Pete (from Winamp Enthusiasts) enthusing about the NxS Big Clock plug-in which he’s been using for quite some time. It’s a small plug-in which provides a time display window with a number of modes from the current elapsed time to the time of day in a large font which makes it easy to see (e.g. when DJing).

However the plug-in is quite old and it doesn’t work too well with most Winamp 5.x releases (*) or Windows (unless you’ve changed folder permissions on the Winamp program folder). To me this is the sort of thing that absolutely needs to be fixed (running Winamp as an administrator or disabling UAC or changing folder permissions is not an acceptable fix) and as the source code (GPLv2 licensed) was available (which I hadn’t realised despite remembering when the plug-in was first created) I thought it was time to fix it.

big_clock.png

So I’m happy to announce the availability of an updated release of the Big Clock plug-in which is based on the v0.5 update by Sebastian Pipping which itself was a modified version of the original plug-in. If you’ve used the plug-in before, then the changelog might be off interest as even small plug-ins can end up needing a fair bit of work to update them.


The next thing is something I’ve already talked about a few weeks ago and related to providing a WASAPI audio output plug-in which I had hoped to be able to make use of the existing YASAPI plug-in since I’d heard good things about it from those using it and with it being open source (GPLv3 licensed) I’d naively assumed that patches to help improve Winamp integration would be welcome (which turns out is not the case and which I’m still saddened by).

Having been contacted by a few users of the plug-in, I’ve since made a decision about what I want to do regarding the plug-in and so I’ve now made available a beta release of modified version of the plug-in as Not So YASAPI which is based on YASAPI v1.7.25 (at the time of posting).

I’ve marked it as a beta release as having made some changes as well as using a different compiler to what the official builds are built by, there might be some small issues that I’ve missed. So if you have any issues or suggestions with this modified beta release of the plug-in, do not make any attempt to report them to the original author (as per his very direct and clear instructions on the matter) and report them instead to me


There was a small but of work done on the Waveform Seeker plug-in to look into an issue with it crashing if the playlist is empty on start-up (the fix is yet to be released) and an odd crash report that I’ve still to complete looking into.

With the crash on start-up issue, that turned out to be an issue in the native MP3 decoder plug-in (in_mp3.dll) not correctly handling an empty string which under normal behaviour isn’t an issue as parts of Winamp do the checking needed to prevent the cause of the crash issue.

But as this plug-in doesn’t follow that (it’s a bit like a mini-Winamp within Winamp) it meant the issue could be triggered. Now this is a simple fix within the plug-in itself but shouldn’t Winamp itself be better handling such problems I thought. Well yes and for the most a fair bit of work was done with the last AOL releases of Winamp to better prevent and fix such crash issues.

Thankfully the nature of the crash showed up exactly what was going on and even better is that it’s something which can be patched to include the extra validation check which is needed without having to touch Winamp’s own source code (who needs that anyway, heh). Additionally it’s something which can be applied to the native Winamp plug-ins so once again by breaking something, I’ve managed to add better handling to more globally fix an issue :)


The next thing is a bit random and as of the time of posting will be left as a bit of a mini-research project. I’d received a question asking about stuttering issues with the main window visualisation display when playing FLAC audio files with the native FLAC input plug-in (which took me a while to finally be able to actually notice).

Knowing that the source code for it isn’t available but the predecessor of it (as from the original FLAC authors as well as a 5.x updated release to add library / metadata support) I thought I’d quickly try and get that working and see if that would also show the issue or not. It turns out it does and that’s about as far as I’ve gotten into looking into the issue.

main_window_sine_wave.png

One of the steps that was used to aid in seeing the issue was to play a 151Hz sine wave (as per screenshot above). Whilst doing this I thought it’d be helpful if I could have a quick way to generate a different tone and I’d remembered was an old SDK example which could do that.

But once I got that SDK example running and cleaned up a bit to be happier with 5.666, I then thought why not add some extra modes to it (as well as see if I could make sense off enough things to do actual audio generation which I’ve not done for a very very long time). So I got a little bit carried away and in a few other modes which are:

Tone generator: sine wave, square wave, sawtooth wave & triangle wave
Noise generator: white noise, brown noise, pink noise

What use this plug-in will have I don’t know (assuming I end up releasing it), but as a means to try to get my mind back around audio generation and a few other things when it comes to input plug-in and audio processing, it was handy to go down this rabbit hole for a bit.

If I do continue working on it to make it releasable, I’d need to finish off a sweep (or chirp) mode (so it changes the frequency from one value to another over a specified time as well as adding the means to control how long the output runs for (since it just keeps playing until manually stopped at the moment).


Related to the tone aspect, one thing I do remember when I was involved with SHOUTcast was that some streaming systems introduce tones into their output, so maybe with the above possible work on this plug-in and better interaction with the normal playback, either a simple short tone in the playlist or a tone overlay could be accomplished.

As I know that there are other streaming solutions to using Winamp but there’s a lot of people who get on with it better than dedicated broadcasting / automation tools (e.g. those who cannot or are not able to deal with installing dedicated database solutions to get a program just running or who just run off a single randomised playlist and that’s all they need). But that’s a whole tangent that I doubt many are interested in if you’re here mainly for Winamp related updates :)


The final notable thing is small follow-up on a point covered last week relating to HTTPS, podcasts and streams. From a bit more testing, it appears that some HTTPS urls will work but the majority of what I’ve been testing (e.g. this) don’t with it seemingly depending on the SSL implementation being interacted with.

This isn’t too much of a surprise as changes over the last few years have attempted to make SSL more secure and so not all implementations are equal or they silently fail and force you down to a non-SSL connection.

The end result of this is that for the podcasts handling, I’ve already got a work around (forcing it to use the non-SSL HTTP only url) and if I want to just allow HTTPS urls to work, I’ll be looking for my podcasts replacement to eventually use a libcurl based solution instead of relying on jnetlib. Though I won’t be doing this for the time being and will likely do a bit more research to come up with a solution that will allow HTTPS to work for anything that gets thrown at Winamp (which is better for the long-term).


So that’s this update of what’s been going on over the last week which hopefully seems a bit more productive than some as there’s actual binaries to play with. Here’s a general summary of what was talked about:

  • Modified Big Clock plug-in released
  • Modified Not So YASAPI Output plug-in beta released
  • Improving Winamp stability in-general via small patches
  • Messing about with FLAC input plug-ins
  • Some tone and noise generator research
  • SSL support is hit and miss, more to do about it later

-dro

(*) But it works for me I hear. Yes for the most part it loads ok but weird menu issues depending on the skin being used, not following the Winamp settings folder, odd display glitches and so on once you start looking at things properly shows that it’s more limping along rather than it really working ok.


Comments:

  1. Why WASAPI and not ASIO? Isn’t ASIO more popular and soundcard supported?

  2. DrO,
    Nice to have WASAPI based plugin for Winamp, but…
    If I remember original author didn’t allow to use his sources. Am I right? (despite that in my opinion license allow to use it by anyone). Also he is very strange and posts strange texts on Winamp forum…
    So, why did you decide to do anything with YASAPI plugin? It seems to be not nice (or not?)

  3. Great progress now with this string of quality plugins Dr O.
    They are all fantastic plugins made even better and more current by you.
    Thanks for the time and effort.

  4. Victor: The main reason for going that route is that WASAPI is an integral part of the OS since Vista and in general it should work correctly no matter what device is being used (though that’s not always the case depending on device drivers and all that fun).

    With ASIO that’s far from guaranteed (often requiring specific support) and so although ASIO is generally deemed the better option, WASAPI (more so in exclusive mode) is near enough but better supported.

  5. Pawel: The YASAPI plug-in is released under a license which allows for anyone to take the code and do with it as they please as long as any code codes (be that new or based on the existing source) is also provided.

    With the beta release of my version plug-in at this stage there isn’t that much different and it might just stay like that. All I’ve done so far is adding in the few things that I’d contacted him about providing a patch for (which was eventually turned down) and ensuring that building it under a different setup still works.

    I really didn’t want to have the issues which have been raised by all of this from what I’ve now found about what has been said and posted including the 2 messages that I’d sent to him which I don’t have any issue with being posted publically as I don’t see how the response that it’s generated could have arisen from them.

    As there were things that needed to be clarified especially in relation the code license so I could correctly follow it correctly when providing a patch or as now happened, a modified release. As there’s a LGPL copying file in one part, GPL in others, the SoureForge page indicates it’s GPLv2 but the source code, etc indicates GPLv3 - so it’s just being sensible to double-check such matters when the information in front of you is conflicting.

    So I’m now in a position where if I were to make my own WASAPI output plug-in, I’m almost certain he’d claim I was just plagiarising his work even if it was written from scratch as I’ve said that I’d already had a look at the available source code for his plug-in.

    And likewise I’m sure there will be some fallout when he becomes aware of the modified release which to my knowledge I’ve followed the GPL license that he has chosen to release the code under which I really don’t understand why do that based on the negative and aggressive reaction to both myself and a number of other users of the plug-in who’ve since contacted me who have been told not to use his plug-in (hence having to go the route of forking and seeing where that goes).

    Finally I’ve tried to make it as clear as possible that a) this is a modified version, b) that it is not supported by the original author and c) what exactly it has been created for (which is to work better with 5.666 as well as common things that a good quality plug-in for Winamp should be trying to do imho).

  6. Thank you for your explanation.
    I hope now everyone knows your position, especially plugin author.

  7. Trying out NS YASAPI and finding it doesn’t save any changes in the Device tab. This was an issue in older YASAPI releases as well but seemed okay recently. For example I’m just trying to switch from Share to Automatic and enable 16bit to 24bit conversion

  8. osm0sis: Thanks for the report and have reproduced it (not sure until I look into it why it would have stopped working when I’ve not changed the save handling). Will aim to get a newer beta build out for early next week as there;s another issue I’ve had reported that I will need to look into.

  9. DrO
    Where can I find on your website some page that aggregate all your plugins that you support/updating now (I mean some short description and link to plugin page). I am asking, because I will make Polish translation for all of them (most of them I already translated. I want to be ready for WACUP launch). Are you going to add them all to WACUP installer?

  10. Hey DrO, Thanks for all the work you do keeping winamp modern. I’ve been a huge fan of your previous plugin releases for many years and I can’t wait to see the end result of this project.

  11. Pawel: There isn’t a page that does that yet as I’ve created it (it would most likely be put up at https://getwacup.com/plugins/) as I’m still trying to work out how existing stuff from my winampplugins site vs what will make up wacup will be done.

    Keen: Thank you :)