[Y]et [A]nother WA[SAPI] [N]ew [T]echnology [Out]put Plugin for Winamp (out_yasapi-nt)

Last updated on 201007-0848

Copyright © 2015-2019 by Peter Belkner <info@pbelkner.de>

[Y]et [A]nother WA[SAPI] [N]ew [T]echnology [Out]put Plugin for Winamp (out_yasapi-nt) (out_yasapi-nt) is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

out_yasapi-nt is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with out_yasapi-nt.  If not, see <http://www.gnu.org/licenses/>.

Please note that any remark on this sites is just art. Of course, its aim is to trigger some thoughts in your mind. But please hesitate projecting them back on us, i.e. don't assume those thoughts are ours

[Y]et [A]nother WA[SAPI] [N]ew [T]echnology [Out]put Plugin for Winamp (out_yasapi-nt) utilizes the Windows Audio Session API (WASAPI). WASAPI's exclusive mode for rendering audio is a native way on Windows to render audio undisturbed, similar to Steinberg's Audio Stream Input/Output (ASIO). YASAPI/NT Output may serve as a replacement for any other Winamp Output.

In order to understand the difference between YASAPI/NT and it's hijacked predecessor YASAPI read this first.

Nanos gigantum humeris insidentes: This project is dedicated to my German heritage. It is strictly to be understood as a statement against the "sweet" liberal lie of "multiculturalism" which is going to destroy Europe as we know it, in particular against the Merkel regime selling out Europe for nothing as we watch. #WLM


Home:   http://pbelkner.de/projects/web/out-yasapi/
Download:   http://pbelkner.de/projects/files/out-yasapi/out_yasapi-nt/
Winamp Forum:   http://forums.winamp.com/showthread.php?t=380396 (discontinued)
Input Plugin:   http://pbelkner.de/projects/web/in-ffsox/
Loudness Normalization:   http://pbelkner.de/projects/web/bs1770gain/
Keep HDD Awake:   http://gen-hdd.sourceforge.net/
Yet Another Shuffle:   http://pbelkner.de/projects/web/yapib/


  1. News
  2. Introduction
  3. Sequence Diagram
  4. Installation
  5. Implementation
  6. Configuration
  7. References
  8. A Message Silently Disappearing from the Winamp Forums
  9. Some Additional Notes Regarding the Lovely Parasite 

Note: You may toggle the size of most images by clicking on them.

1. News

Date Release Remarks
  • As it seems our days at Sourceforge are counted. At least we’ve received a respective ultimatum:

    Isn‘t it funny that this is happening at the exact same time as Donald J. Trump is going to crack down all that commie scum?

  • 2020-06-09 − These days where anything and everything has a motto it remains Sorceforge’s secret why prohibiting a motto in favor of one’s own people. Anyway, we’re going to leave: In order to comply formally with their ”policies“ this page ill simply be replaced by something similar to dummy-doc/index.html.
  • 2020-06-14 − The project has been moved to http://pbelkner.de/.
  • 2020-06-30 − We’ve changed the above tag: #TeamWhite#WLM.

    (C) by FOCUS Online
  • By pure accident we’ve stumbled across this:

    “I won’t be trying to update it to use YASAPI/NT since despite the code licensing the author of the plug-in has not made using GPL’d code a nice experience nor has their actions to numerous users been nice to see).”: Ha, ha, ha, spast: Treffer, versenkt!!! For sure, you’ll never again will go and steel away our software :-)))))))))))))))))))))))))))))

  • 2020-06-24 − We simply did what we’ve promised to RMS himself:

  • Chris reported that the plug-in seemed not to load on Windows 10.
  • Fortunately, this could be resolved by using the plug-in's gcc version.
  • Hence we changed the default download from msc-bundle to gcc-bundle.
  • Please note that the plug-in is developed on Windows 7.
2019-10-31 2.3.5 Made the plug-in more robust for being run from an unexpected environment. (Many thanks again Ralf!)
2019-10-21 2.3.4
  • Brought back the dialog for choosing the installation directory of the GTK runtime (cf. below) which for some unknown reason had been vaporized (thanks a lot Ralf.)
  • Corrected counting broken sessions.
  • In case you try downloading "winamp58_3660_beta_full_en-us.exe" from the source (i.e. from winamp.com) you may experience that it's not possible because their certificate has been expired (already for some time):
  • It's, of course, possible to download e.g. by means of the wget command:
    # wget 'https://download.nullsoft.com/winamp/client/winamp58_3660_beta_full_en-us.exe' --no-check-certificate
    --2019-06-02 07:24:43--  https://download.nullsoft.com/winamp/client/winamp58_3660_beta_full_en-us.exe
    Resolving download.nullsoft.com (download.nullsoft.com)...
    Connecting to download.nullsoft.com (download.nullsoft.com)||:443... connected.
    WARNING: cannot verify download.nullsoft.com's certificate, issued by ‘CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US’:
      Unable to locally verify the issuer's authority.
    HTTP request sent, awaiting response... 302 Found
    Location: https://download.nullsoft.com/winamp/misc/winamp58_3660_beta_full_en-us.exe [following]
    --2019-06-02 07:24:44--  https://download.nullsoft.com/winamp/misc/winamp58_3660_beta_full_en-us.exe
    Reusing existing connection to download.nullsoft.com:443.
    HTTP request sent, awaiting response... 200 OK
    Length: 8201952 (7.8M) [application/x-msdos-program]
    Saving to: ‘winamp58_3660_beta_full_en-us.exe’
    winamp58_3660_beta_full_en-us 100%[=================================================>]   7.82M  1.68MB/s    in 4.8s
    2019-06-02 07:24:48 (1.64 MB/s) - ‘winamp58_3660_beta_full_en-us.exe’ saved [8201952/8201952]
  • Update: Seems to be fixed.
2019-05-28 2.3.3
  • Most likely you've read the following message a few days ago appearing on the Winamp forum:
  • Because of that we ask some of our users we're convinced really exist whether they can confirm because we're on a hopelessly outdated Windows 7 system and hence cannot tell whether it's running on Windows 8.1 or Windows 10 (apart from technical issusses caused by drivers and devices.)
  • As expected, the only thing they confirm is that it's up and running. Many thanks to everyone contributing to the survey!
  • One of the users, Diimaan from India, took the opportunity to report some problems he experienced on his system with exclusive mode where calling the IAudioClient::Initialize method was returning with some error message.
  • Jointly we where able to resolve the issue with exclusive/push (you may have noticed undocumented v2.3.3-β1, v2.3.3-β2, v2.3.3-β3, and v2.3.3-β4 needed for respective communications):
    • The error code returned was AUDCLNT_E_UNSUPPORTED_FORMAT, an error code
    • This brouht us to the idea to introduce an additional call to IAudioClient::IsFormatSupported in front of IAudioClient::Initialize and voilà the issue was fixed. (Please note that to our knowledge it is undocumented that calling IAudioClient::IsFormatSupported in front of IAudioClient::Initialize is mandatory.)
  • Unfortunately, it was not possible to resolve the issue with exclusive/pull where on Diimaan's system calling the IAudioClient::Initialize method repeatetdly returns with error AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED:
    • Error AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED should be healed by the alignment dance.
    • Unfortunately, this doesn't help here because the alignment dance has alredy taken place (indicated by repeatedly contained in YASAPI/NT's error message.)
    • Anyway, we found a bug in YASAP/NT's implementation of the alignment dance and fixed it. Unfortunately, this doesn't help either (we on our system are not able to test the alignment dance's implemetation because error AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED is not appearing.)
  • Thanks a lot Diimaan!
  • This release is bundeled with the latest v190528-0620, of the GTK+ runtime.
2019-05-12 2.3.2 A few days after having published the below fix, the issue appeared again on our system. Of course, it is not sufficient to just have the event object in place, we should also fire it when un-pausing! (Viewed this way the additional event object might be completely superfluous - anyway, it doesn't hurt.)
2019-05-12   Ratatosk: German Doomer caught on camera
2019-04-06 2.3.1
  • In very rare cases we observed a deadlock when un-pausing with YASAPI API being active.
  • We hope we've solved the issue by deploying a dedicated event object for synchronizing the YASAPI API.
2019-03-14   Finally identified the root cause for stuttering and fixed it. That way we confirmed our hypothesis that it was caused by loading due to the input plug-in.
2019-02-28 2.3.0
  • We're proud to announce that finally v2.3.0 has been released.
  • It's essentially the same as v2.3.0-β13.
  • It uses the latest GTK runtime providing updated versions of gspawn-win32-helper.exe, gspawn-win32-helper-console.exe, libgdk-3-0.dll, libgio-2.0-0.dll, libglib-2.0-0.dll, libgmodule-2.0-0.dll, libgobject-2.0-0.dll, libgtk-3-0.dll, libharfbuzz-0.dll, libpango-1.0-0.dll, libpangocairo-1.0-0.dll, libpangoft2-1.0-0.dll, libpangowin32-1.0-0.dll, libpcre-1.dll, and libpixman-1-0.dll.
2019-02-02   Recently we observed what is best described as some irregularity regarding the Sourceforge download figures.
  • Starting with 2019-01-18 there's an obvious pre 2.0+ versions boost contributing significantly to the overall figure:
  • With low contributions it scatters through most of the pre 2.0+ versions:
  • Who might have an interest in manipulating the download figures (e.g. by running a background job on low frequency performing automatic downloads) in favour of the (outdated) pre 2.0+ versions?
  • Update 2019-02-03: We're able to narrow the irregularity

    and sharply can say that it is made from servers located in Poland and France (ignoring a small noise floor):
  • Update 2019-02-21: A few days after having made public the above anomalie it's slowly disappearing:

    Treffer, versenkt (hit, sunken)
2019-02-02 2.3.0-β13 Fixed the default setting for option Priority of Winamp's Thread when Draining.
2019-01-14 2.3.0-β12
    Introduced some new or altered, respectively, snake oil options:
    • Introduced an option for increasing the (audio) renderer thread's priority. Might be useful for stabilizing audio output when in lowest latency double buffered mode and in parallel e.g. browsing the internet. Switching to Above Normal might be sufficient to avoid any disturbtion:
    • Replaced the Priority Boost option (indeed nothing other than snake oil) by two options for temporarily (i.e. when draining)
      • increasing the priority of YASAPI/NT's (audio) renderer thread (it's ignored if chosen not higher than the option described above), and
      • decreasing the priority of Winamp's thread:
    • In case you're using this plug-in in conjunction with our FFSoX input plug-in you might further improve audio stability by decreasing FFSoX's video renderer thread prirority (since FFSoX
    • Why we're trying to sell those snake oil?
      • As already pointed out on our system from time to time we observe kinda stuttering at the end of tracks when in lowest latency double buffered mode.
      • It might appear in gapless mode mostly with video tracks but isn't constrained to it.
      • Our hypothethis is that it is due to avformat_open_input called by FFSoX's play method from within Winamp's thread (in gapless mode might already open the next track when in parallel still draining the previous track from within FFSoX's audio render thread.)
      • We're trying to fight this unwanted behaviour by
        1. improving the audio renderer thread prority in general,
        2. boosting the audio renderer thread prority when draining (i.e. at the end of a track),
        3. lowering Winamp's thread (from where avformat_open_input is called) prority also when draining, and
        4. lowering the video renderer thread prority in general.
      • We're on a somewhat outdated 2008 i7 Windows 7 system (upgraded from Vista.) It might be that a more decent system has improved thread scheduling and doesn't stutter at all.
2019-01-10 2.3.0-β11
  • In a lot of cases simplified communications between engine client and engine server.
  • Got rid of engine client Open state.
  • Introduced engine server Render state:
  • Various fixes (e.g. the counter of Broken Sequences hadn't worked as expected: from time to time it might happen that the number of audio frames cached in YASAPI/NT's buffer is not sufficient to bridge the gap between tracks ‐ the sequence is broken; with this β-release the counter should be fixed.)
2019-01-06 2.3.0-β10 Some special care must be given to some input plug-ins writing variable size packets to the output plug-in (notably "in_mp3".) We've overlooked to migrate this feature from v2.2.0-β5 to v2.3.0-β1. It's corrected with this β-release.
  • Lovely Parasite , may we remind you on your promise?
  • Is that all???
  • Erreicht den Hof mit Mühe und Not;
    In seinen Armen das Kind war tot.
    He reaches his courtyard with toil and with dread, –
    The child in his arms finds he motionless, dead.
    Johann Wolfgang von Goethe: Erlkönig
  • Not reached yet, surprise, surprise: "the public WACUP preview build is now aimed for the 1st or 2nd"
  • Lovely Parasite  (the future of Winamp ), guess what? We're tired of waiting.
  • Update 19-01-03: The Lovely Parasite  finally has shipped its effort. We've given it a try:
    • First impression: Trying to install in portable mode (on a system partition) crashes.
    • It still comes with a stolen version of this plugin (cf. here and here. BTW: That's the only innovation since ages regarding Winamp's core functionality: audio reproduction.) The plug-in's crash seems to be "fixed" just cosmetically: double buffered mode now simply does not work (without notice.)
    • Summary: This is a "product" nobody needs. Nothing other than GUI gimmicks without any benefit we had to wait for about three years The future of Winamp
    • Because we don't want to further honor the Parasite we've decided to stop commenting on it because we feel that the ones really interested in WASAPI will find their way to this page anyway and will not support the Parasite's effort just because of WASAPI.
    • Thanks again to the talented engineers at Nullsoft who had designed already by the late nineties an API to Winamp still open enough these days for low-latency audio, and the engineers at Microsoft for crafting WASAPI.
  • Update 19-01-05: How does it go that the Parasite's effort (technically nothing other than a wrapper to an outdated Winamp) is hyped by some MSM as soon as it appeares (delayed by half a year according to the Parasite's primary announcement)? Why the Parasite got stuck to an outdated Winamp and does not upgrade to a decent version? Think about it! (Hint to the latter: Even Herrschaftswissen is getting outdated when not getting refreshed )
  • Update 19-01-19: As of today there's another Lovely Parasite's  victim: Otachan who made the source code of his famous out_asio plug-in publicly available:

  • Update 19-05-23: As an answer to a post hyping the Parasite as the The future of Winamp a message appeared on the WA-forum perfectly nailing down what's going on there:
  • Update 19-05-30: Those SJWs really believe they're the good ones

    where indeed they're nothing other than crypto-communist parasites, e.g. radio presenter and general purpose nerd:

    Please note what this particular idiotic SJW is letting us know about his occupation: Evil Genius.
    MWAHAHAHAhahahahahaaaaaaa. . aaa.aaa.aa...a...a.a
    *cough cough cough*
2018-12-30 2.3.0-β9
  • Inserted a group Engine State on the Configuration dialog's Monitor page. Because it made the dialog by far to large this particular page was broken up into a Notebook control:
  • Did similar with the Common page.
  • Still struggeling with some instabilities. Hopefully it's getting smoother now!
  • Needs v181225-1111 of the GTK Runtime upgrading libatk-1.0-0.dll, libcairo-2.dll, libcairo-gobject-2.dll, libdatrie-1.dll, libepoxy-0.dll, libexpat-1.dll, libfontconfig-1.dll, libfribidi-0.dll, libgcc_s_dw2-1.dll, libgdk_pixbuf-2.0-0.dll, libgio-2.0-0.dll, libgmodule-2.0-0.dll, libgraphite2.dll, libharfbuzz-0.dll, libintl-8.dll, libpango-1.0-0.dll, libpangocairo-1.0-0.dll, libpangoft2-1.0-0.dll, libpangowin32-1.0-0.dll, libpixman-1-0.dll, libpng16-16.dll, libstdc++-6.dll, libthai-0.dll, libwinpthread-1.dll, and zlib1.dll (bundled with the respective installers.)
2018-12-18 2.3.0-β8
  • Slighly changed the semantics of the Priority Boost option: attached it to YASAPI/NT's Draining phase which in allmost all cases is equivalent to former Close to Open.
  • Visually moved the Priority Boost option close to the Gapless Playback option and let it appear a sub-option to the latter (which indeed it is):
  • In case you're using this output plug-in in conjunction with the FFSoX input plugin you should upgrade to FFSoX v0.5.1.
2018-12-13 2.3.0-β7 Next try:
  • We have to solve a real life problem (not a problem from a text book): How to get rid of stuttering at the end of gaplessly played tracks?
  • We have already a promising hypothethis on what might cause that nasty stuttering.
  • We did some experiments in order to validate the hypothethis by measuring the time interval between events fired by the respective Event Object (by means of the GetSystemTimeAsFileTime function) and found that they might correspond to buffer sizes by far exceeding the size of WASAPI's buffer.
  • We searched the whole internet and finally found the promising looking function SetProcessPriorityBoost:
  • Who knows the whole Windows API? Of course, we're not. That's one of this project's targets: to learn something.
2018-12-13 2.3.0-β6 Next try:
  • We have to solve a real life problem (not a problem from a text book): How to get rid of stuttering at the end of gaplessly played tracks?
  • We have already a promising hypothethis on what might cause that nasty stuttering.
  • We did some experiments in order to validate the hypothethis by measuring the time interval between events fired by the respective Event Object (by means of the GetSystemTimeAsFileTime function) and found that they might correspond to buffer sizes by far exceeding the size of WASAPI's buffer.
  • We searched the whole internet and finally found the promising looking function SetProcessPriorityBoost:
  • Who knows the whole Windows API? Of course, we're not. That's one of this project's targets: to learn something.
2018-12-12 2.3.0-β5
  • With gapless playback and double bufferd mode on our system we observed the following strange behaviour (especially with live tracks played with the FFSoX input plug-in which should end apruptly during applause):
    • At the end of such a track from time to time there is kinda stuttering.
    • Finally we had the idea the cause for this strange behaviour might be heavy load during the avformat_close_input/avformat_open_input operations (especially the latter one.) Too heavy for this plug-in's render thread to continue undisturbed, i.e. firing the respective Event Object might come at a time when re-filling WASAPI's render buffer is overdue (another cause for dropouts in double buffered mode we don't have any means to count.)
    • Assuming the above theory is true the responsibility to solve the above issue is, of course, the input plug-in. Anyway, for experimental reasons we provide a solution which should be valid for any input plug-in following the protocol known from the Nulsoft example for an input plug-in:
      • Example code for the input plug-in's stop method:
        1. Close the output plug-in.
        2. Close the respective resource (corresponds to calling avformat_close_input).
      • Example code for the input plug-in's play method:
        1. Open the respective resource (corresponds to calling avformat_open_input).
        2. Open the output plug-in.
      • We assume that both, the stop as well as the play, methods are called from the same core Winamp thread.
    • This opens the door for manipulating the core Winamp thread's priority when the input plug-in goes from closing to opening the output plug-in from within the output plug-in by means of the SetThreadPriority method, i.e. manipulating the thread's priority (i.e. lowering it) during close and restoring it during open when playing back gaplessly. (Please note that the resource intensive call to avformat_open_input while still playing back only happens when playing back gaplessly.):
    • Please note that this is an experimental option we're not fully satisfied with.
  • You might remember discussing the final playback cycle. Meanwhile we had another look at the example provided by Microsoft. This β-release uses an approach correponding to a slightly modified version of the example. Indeed, we don't understand why Microsoft prefers sleeping in favour of (more naturally) waiting for the next event.
  • Still struggling with the already mentioned instability during skip. Hopefully found the root cause (there where unwanted EnterCriticalSection/LeaveCriticalSection pairs when updating the GUI) and fixed it.
2018-12-08 2.3.0-β4
  • Introduced integration with the FFSoX Player input plug-in:
  • Starting with this β-release YASAPI/NT exports an interface each input plug-in is invited to use in interacting with the output plug-in (of course we know that nobody other then us will do ).
  • The advantage of this interface is that an input plug-in is not required to wait for an arbitrary time when not enough space is avalaible for writing (cf. busy waiting in the Nullsoft example for an input plug-in.) Instead the output plug-in waits inside the interface's Write() mehod on an event object until the requested space is available.
  • In an analog way busy waiting for the end of track has to be substituted by a call to the interface's EndOfTrack() method.
  • Unfortunately, if you're using gapless playback the latency is bounded from below by the amount of samples needed to be cached in order to bridge the gap from one track to the next. May be we can relax this by furter working on the FFSoX Player and Yet Another Shuffle plug-ins. Anyway, you may observe at least that buffer fluctuations dramatically reduce until close to vanishing (by watching the respective monitor control) when trying one after the other: integration off, integration internal, and integration external.
2018-12-06 2.3.0-β3
  • Finally enabled gapless playback.
  • Introduced a control for monitoring the maximun, previous, and minimum bridged gap, resepectively, between tracks of a gapless sequence:
  • (Hopefully) fixed an instability when skipping (a possible deadlock.)
2018-12-01 2.3.0-β1
  • As announced with v2.2.0-β5 we're back again with a new release based on a modified architecture.
  • While working on the documentation (now frozen into v0.1) we came to the conclusion that we should split class WASAPI Engine into it's Client/Producer and Server/Consumer parts.
  • While at it we discovered that it would be advantageous to factor out from both a common functionality into something we called Finite State Machine (FSM). It's not the most general FSM we can imagine because each of our states has the special property of having exactly one incoming edge and exactly one outgoing edge (you may have noticed this from documentation v0.1). Hence our FSM is not able to take into account any history.
  • The implementation of our states is along the lines of a preprocessor pattern described to some extend in section "Printing enum values as strings" here.
  • Then we had the idea that we could apply the same technique to the GTK thread.
  • Finally we had the idea that on user request we could create another thread based on the exact same pattern bringing the dialogs in front of the visualizaton with a certain frequeny replacing the per dialog position options:
  • Our next plans are
    • v2.3.0-β2: gapless playback, and
    • v2.3.0-β3: integration with the FFSoX player input plug-in.
  • A series of messages appearing on the WA forum made us aware that Radionomy might have silently(!) retract Winamp 5.8 (cf. here, here, here, here, here, here, here, and here):

  • We confirm that this really is the case (cf. the lower left corner of the following image displaying the link from where the mouse is over; and in case the mouse is over the download button it is not pointing to any download but to the top of the current page):
  • Cf. also the corresponding anchestor's href attribute:
  • We don't know whether this has to do with Benski's WASAPI output being nothing other than rubbish. Anyway, this gives us the perfect opportunity to point out that the history of Winamp seems to us the perfect model to the history of (western) societie's governements: The once leading edge technology company Nullsoft during the years has gotten into the hands of people appearing to us just like a bunch of betrayers (especially not respecting intellectual property) just like the (western) societie's governements. To name a few w.r.t. Winamp:
    • the Lovely Parasite  (cf. here),
    • the Senior Director of Engineering at iHeartRadio, Ben Allison (cf. here) aka Benski, (cf. here),
    • the WA forums's moderator Pawel (cf. here - update 2018-12-17 - and here),
    • the self-proclaimed Humanitarian (cf. here ) and Radionomy employe DJ Egg (cf. here)
    • and more;
    w.r.t. (western) societies cf. e.g. here, here, and (update 2018-11-30) especially here (anyway, we miss at least a clear statement regarding 9/11 in order to fully believe in this. Update 2018-12-10: You might read this.)
  • Finally (we noticed it in the evening) Radionomy has brought back the download link. The least one can say regarding this episode is that it does not look very professional

Anyway, we have a similar problem: This plug-in might crash with Winamp v5.8 when unpause. Hopefully this will be fixed with the next version.
Update 2018-10-25: This was due to a feature of the FF (mpeg and) SoX 2a Input plug-in not published yet.
  • The Lovely Parasite  has fresh promises
  • And of course, he wants your shekels just based on empty promises:
2018-10-20 2.2.0-β5
  • Another β-release as a direct consequence of working on the documentation.
  • Got rid of class Request including enumeration ERequest.
  • Got rid of HANDLE hEot.
  • Renamed state eEngineEot into eEngineDrainingDoubleBuffered and changed it's semantics accordingly.
  • Fixed a subtle synchronization issue (i.e. missing case eEngineBase. Note: In case the link is not working as expected open it using Open Link in New Tab.)
  • The current state of the documentation is frozen into v0.1.
  • This β-release might mark the end of the v2.2.x-releases because we came to the conclusion that it's best to split class Engine into it's Client/Producer and Server/Consumer parts.
  • We'll might be back some day with v2.3.0-β1 hopefully reproducing what we have today.
  • Radionomy has an official Winamp v5.8 out:
  • It is equipped with a Nullsoft WASAPI Output plug-in:
    • The author of the plug-in is one out of the talented Nullsoft engineers (Ben Allison aka Benski):
    • Unfortunately, there seems no Configuration dialog.
    • Too sad, it does not work for us even if we don't operate an esoteric device (cf. here.) There's not the slightest sound coming through.
    • Update 2018-10-20: For us Benski's WASAPI Output not only does not work but it also mutes the standard Nullsoft DirectSound Output as well as YASAPI/NT Output's two shared modes. Finally we figured that it's possible to re-animate Nullsoft DirectSound Output as well as YASAPI/NT Output's two shared modes but not Benski's WASAPI Output by in-between using Nullsoft WaveOut Output. Benski, what have you done? Anyway, we really like the new Big Bento Modern skin
    • Moreover, there's no hint in which mode Benski's WASAPI Output is operated, i.e. whether in exclusive/pulled (double buffered) mode, or in exclusive/pushed mode, or in shared/pulled mode, or in shared/pushed mode. Just WASAPI. (Update 2018-10-20: What is described above and what appears to us as a severe bug of Benski's WASAPI Output is a strong hint towards it is attempted just to operate in one out of the shared modes, i.e. in a mode just eqivalent to DirectSound.) Having Winamp labelled WASAPI seems sufficient for marketing.
    • Update 2018-10-20: The Winamp forum announces Benski's effort at position one marked as w.i.p. (we read work in progress):

      They've forgotten to mention that it might not work at all and that trying it might break DirectSound Output.
    • Sorry Benski, it was a nice try. But there's still a lot of work just around the corner. Update 2018-10-21: Possibly not what a Senior Director of Engineering is looking for (cf. also here)
  • Update 2018-11-23: Because on some systems Bensk's effort does it's job at least to some extend we'd like to provide some information on our system (we confirm that we can bring Benski's effort to life also by moving the volume slider):
    • We're on Windows 7.
    • The driver seems to be provided by Microsoft, i.e. is standard:

    • The product itself is an inexpensive one from Amazon.
  • Update 2018-11-24: Several messages appearing on the WA forum meanwhile confirm that we're not spooky and that Benskis's effort is indeed nothing other than rubbish (cf. here, here, here and here):
  • The best of all: the Lovely Parasite  is whining
2018-10-17   Sometimes the Lovely Parasite  got something right
2018-09-28 2.2.0-β4
  • Had a second look at the Microsoft text-book example on rendering Exclusive-Mode Streams while working on the documentation and ask ourselves how we came to the impression that an extra half-cycle has to be added when indeed it is a full cycle needed to drain the WASAPI buffer.
  • Finally had an idea on how the usage of the (somehow artifical and in-accurate at least on the required time-scale) Waitable Timer Object could be avoided at all: We could add an additional cycle with silence and when the time comes to play this cached cycle we simply end playback.
  • As a result there are now two options for adding the additional cycle when in double buffered mode (i.e. when in exclusive pulled mode):
  • Re-structured some of the GUI-code (e.g. Droput is counted now in audio fames and ms, respectively.)
  • Improved the (still draft) documentation.
2018-09-28   The GTK runtime's v180928-1502 providing updated versions of gspawn-win32-helper.exe, gspawn-win32-helper-console.exe, libgdk-3-0.dll, libglib-2.0-0.dll, libgobject-2.0-0.dll, and libgtk-3-0.dll is available.
A fix to correct the fix to correct the fix just within five days. All just in order to entertain the lovely beta testers
Note: Don't get us wrong. We know what it means to manage complex software systems. Anyway, we don't hype ourselfs nor being hyped by somebody else as the future of Winamp (what indeed needs some kind of organization instead a single individuum) when in reality just stealing away somebody else's work:

Of course, the Lovely Parasite  is a Good Guy®. We don't have the slightest doubt. But believe us, we really don't want belong to (((those))) good guys
2018-09-16 2.2.0-β3 We just observed that time reporting was completely broken when the Report Latency Instead of Time optimization was not chosen (possibly already for a longer time.) This β-release fixes the oddity.
2018-09-16 2.2.0-β2
  • This β-release should be without any effect to the plug-in's functionality.
  • We re-structured the build-process by means of the m4 macro processor in order to get rid of allmost all YASAPI prefixed C preprocessor symbols from the published source code.
  • The aim of this β-release is to some extend make sure that everything has survived this transformation.
  • Please have in mind the above note.
  • Got rid of state eEngineDrainigFinal.
  • Added a (missing) final half cycle to double buffered playback (cf. the usage of a Waitebale Timer Object at the Microsoft example for rendering Exclusive-Mode Streams.)
  • The latter two points are direct consequences of thinking twice while working on the documentation.
2018-09-14   Meanwhile the Lovely Parasite  confirms that its announcement from 2018-09-05 was nothing other than fake news (due to its "creative" approach to reality ):

We still have doubts that build #2770 really exitsts available to somebody other than the Lovely Parasite  itself because there's still no corresponding entry at the Winamp Ramblings blog (as it usual is the case):

Please note that according to its own words since november last year the Lovely Parasite  has crafted nothing other than bug fixes
2018-09-08   Version 180908-1913 of the GTK runtime providing ugraded versions of gspawn-win32-helper.exe, gspawn-win32-helper-console.exe, libgdk-3-0.dll, libglib-2.0-0.dll, libgobject-2.0-0.dll, and libgtk-3-0.dll is available.
2018-09-06   That's exactly how naïve believers look like:

Kinda funny
Lovely Parasite , this announcement is a vaporware par excellence: No download link available not even for the registered naïve "lovely beta testers" and no corresponding entry to the Winamp Ramblings blog. Instead: "The update flag will be set in a few days & all beta requests will be followed up over the next few days." (Cf. also here and here.) As already mentioned, we're still waiting for the public release announced a long time ago.
BTW: Triggering the Lovely Parasite  is real fun!
2018-09-01   We're aware that we're not the world's most gifted software developer. Anyway, we feel that we belong to #TeamWhite and hence added the respective hashtag to the above note.
Lovely Parasite , we ment a public release (according to your annoncements it's overdue anyway) not just another vaporware just available to your naïve registered believers.
BTW: Its "creative" approach to reality along with its parasitic behaviour and its greed for shekels seems an indication to the Lovely Parasite's  nationality. Anyway, at least it appears to be strongly influenced by (((those))).
2018-08-30   Loading this site's online version became slower and slower because we've got lots of images in section News. That's why for the online version we introduced incremental loading of section News by means of some technics known from dynamic HTML notably XMLHttpRequest. The site's previous version is available here.
2018-08-26   Published a Sequence Diagram.
2018-08-25   runtime is available.
2018-08-18 2.2.0-β1
2018-07-15 2.1.0
  • Allmost the same as v2.1.0-β6 except some code cleanup.
  • Next steps might be:
    • v2.2.0-β1  Reorganization of YASAPI/NT's buffer in order that it better suits gapless playback.
    • v2.2.0-β2  Gapless playback.
  • From the Lovely Parasite's  Twitter account:
  • As Twitter user Jeremy King puts it (including another spooky remark by the Lovely Parasite ):

  • Twitter user Daria comments:
  • Twitter user J.R. Raith with a fine irony regarding the Lovely Parasite's  abilties:
2018-06-24 2.1.0-β6
  • Fixed a subtle bug with Dithering.
  • Restructured time reporting functions, i.e. getwrittentime() and getoutputtime().
2018-06-24   Version 180620-0644 of the GTK runtime providing ugraded versions of libfribidi-0.dll, libharfbuzz-0.dll, and libintl-8.dll is available.
2018-06-03 2.1.0-β5
  • Introduced Dithering:
  • You might ask yourself what Dithering is:
    • First of all: Dithering makes only sense when reducing bit depth, say from 32 to 24 or 16 bits. Otherwise simply 0-bits will be padded.
    • When throwing away bits you might think a moment on how doing it. What next comes to mind is Rounding.
    • You might view Dithering as a generalized form of Rounding. When Rounding a constant value of half of the number of bits to throw away all set is added before shifting to the right by the number of bits to throw away (that way actually throwing them away.) Dithering generalizes this approach by not just adding a constant value but a value over time fluctuating from 0 to the number of bits to throw away before shifting to the right. This randomized version of Rounding is aimed to break interference pattern known as quantization noise.
    • Currently YASAPI/NT implements a simple Dithering algorithm (without noise shaping) following the idea sketched at https://www.kvraudio.com/forum/viewtopic.php?t=132643 under consideration of http://c-faq.com/lib/randrange.html.
  • Please note that this is also Поднятая целина. Not a single prior (or hijacked) version of the plug-in is supports Dithering.
2018-06-01   v180531-1449 of the GTK+ runtime have been published. It contains updates to the following executables and DLLs: gspawn-win32-helper.exe, gspawn-win32-helper-console.exe, libatk-1.0-0.dll, libepoxy-0.dll, libgio-2.0-0.dll, libglib-2.0-0.dll, libgmodule-2.0-0.dll, libgobject-2.0-0.dll, libiconv-2.dll.
2018-05-27 2.1.0-β4
  • Introduced support of Volume Control for Exclusive Mode playback due to WASAPI interface IAudioEndpointVolume (once scheduled as v2.1.0-β3).
  • Interface IAudioEndpointVolume is ab bit more special than Interface ISimpleAudioVolume because there must be hardware support for volume control.
  • YASPI/NT tests whether there is hardware support for volume control by means of the IAudioEndpointVolume::QueryHardwareSupport method. If not it falls back to it's own software solution as is illustrated by the following images:

    The image on the left hand side shows a device with hardware support wheras the image on the right hand side shows one without.
  • Please note that this as well is Поднятая целина. Not a single prior (or hijacked) version of the plug-in is supporting WASAPI interface IAudioEndpointVolume.
2018-05-20 2.1.0-β3
  • The next regular update once scheduled as v2.1.0-β2 introducing support of Volume Control for Shared Mode playback by means of WASAPI interface ISimpleAudioVolume.
  • Replaced check box Volume Control by a respective combo box:

    The combo box offers the following entries:
    • Off  corresponds to the former check box being unchecked, i.e. no Volume Control at all,
    • YASAPI/NT  corresponds to the former check box being checked, i.e. Volume Control by means of a simple software algorithm provided by YASAPI/NT,
    • WASAPI  correspons to Volume Control depending on what is chosen by means of check box Mode, i.e.
      • when Shared  by means of WASAPI interface ISimpleAudioVolume,
      • when Exclusive  potentially (propably with the next β-release) by means of WASAPI interface IAudioEndpointVolume (with this β-release just by the software algorithm provided by YASAPI/NT).
      • What YASAPI/NT really applies is displayed at Monitor page.
  • Please note that this is Поднятая целина. Not a single prior (or hijacked) version of the plug-in is supporting WASAPI interface ISimpleAudioVolume.
2018-05-18 2.1.0-β2
  • This is an irregular update. Hence no new features. Just re-compiled with the new GTK+ runtime v180518-1351 depending now on zlib1.
  • Created NSIS installers with GTK+ bundled because they might be preferable for some casual user over dealing with a second download and installation.
  • BTW: Prior (and most likely as well hijacked) versions of the plug-in crash when used with Double Buffered mode, i.e. with Exclusive Pulled mode:

    Please note that versions 2.0.0-β1+ have NOTHING IN COMMON with prior (or hijacked) versions (except part of the brand and of course some ideas). That's essential YASAPI/NT vs. YASAPI.
2018-05-13 2.1.0-β1
  • With this β-release check box Volume Control is enabled:
  • When checked, volume control due to a simple algorithm implemented by YASAPI/NT is enabled (i.e. no dithering nor accessing WASAPI interfaces.)
  • Different to prior (or hijacked) versions of the plug-in the algorithm is applied when reading from YASAP/NT's buffer and writing to WASAPI's buffer. (Prior - or hijacked - versions of the plug-in did it when writing to the plug-in's buffer.) You'll immediately notice the difference: now there's practically no latency when moving Winamp's volume slider.
  • What is chosen by means of Volume Control is reported on the Monitor page:
  • The Lovely Parasite  on his WEB site with time stamp 2016-12-29 02:22 has published an updated version of the Winamp SDK expressing his Herrschaftswissen (might be translated by domination knowledge):

    We mention that because from it we've learned something interesting being valid just for Winamp 5.64+. You might consider this a prerequisite for this β-release and all what follows. We'll not going to C-include those header files but make deliberately use of what we've learned (starting with this β-release.)
  • BTW: We're not certain on whether Winamp's current owner, Radionomy, is amused on the Lovely Parasite's  effort. As it seems way back already in late 2016 the Lovely Parasite  was forced by means of a legal complaint due to Radionomy to deliver the following statement along with changing its effort's URL:
2018-05-09   Version 180504-1316 of the GTK+ runtime is available. (No version change visible from the surface but at least an updated version of libiconv is contained.)
2018-05-06 2.0.0
  • Essentially the same as v2.0.0-β10 except some minor changes, of course:
    • At last minute we've changed writing YASAPI NT to YASAPI/NT (with a slash). In order to avoid too much slashes it now reads YASAPI/NT Output v2.0.0 (msc) or YASAPI/NT Output v2.0.0 (gcc), respectively, i.e. the compiler used is appended within braces.
    • Upgraded from Visual Studio Express 2012 to Visual Studio Express 2013 resulting in a minor updated msc version: from 18.00.3201 (cf. below) to 18.00.40629:

      After all we don't use Visual Studio anyway except two command line tools out of the bunch:
      1. the C compiler cl.exe, and
      2. the library manager lib.exe.
  • Please note that the first of the below mentioned limitations is already removed, i.e. format (mono to stereo and bit depth) conversions are yet available.
  • This milestone should provide a basis solid enough for moving on.
  • The next milestone will be v2.1.0 Volume Control (cf. milestones.) Our goal is not just provide some simple software solution but also support the ISimpleAudioVolume (for Shared Mode playback) and the IAudioEndpointVolume (for Exclusive Mode playback) WASAPI interfaces.
  • Hence next we'll have the following refined targets:
    • v2.1.0-β1:  Volume Control by means of software provided by YASAPI/NT,
    • v2.1.0-β2:  Volume Control for Shared Mode playback supporting the WASAPI ISimpleAudioVolume interface, and
    • v2.1.0-β3:  Volume Control for Exclusive Mode playback supporting the WASAPI IAudioEndpointVolume interface.
  • Following is the perfect answer to the question from the Lovely Parasite's  forum: Post (Oct 21, 2017) taken from the guru3D forums makes the essential point (although the guy seem to mix up WASAPI with ASIO and that one should fall back on Shared Mode only if Exclusive Mode for some reason does not work. Only in case Shared Mode is used with the same format configured with Control Panel → Hardware and Sound → Sound → Playback → Device → Properties there should be no difference to Exclusive Mode):

    This guy apart each theory experienced the huge potential w.r.t audio reproduction each PC has due to WASAPI. The only thing YASAPI/NT adds is to make this potential available to Winamp users.
  • Tip: We're digitally connecting our PC to the amplifier by using an inexpensive WASAPI enabled USB to coaxial/TOS adapter and that way using the quality DAC build-in to our amplifier in order to convert from the digital to the analog domain. (We've ripped our CD collection into loudenss normalized FLACs - most importantly a lossess format - and like listening to it in Winamp random mode.)
2018-05-05   Version 180503-0953 of the GTK+ runtime is available. (No version change visible from the surface but at least an updated version of libcairo is contained.)
2018-04-30   Uploaded version 180426-0807 of the GTK+ runtime lifting libgtk's version from 3.22.29 to 3.22.30 (cf. v180412-1003):
2018-04-29 2.0.0-β10 Fixed label Device Period erroneous linked to combo box Strategy and not to combo box Mode as it should be.
2018-04-28 2.0.0-β9
  • Just discovered that the combo box advertised with v2.0.0-β6 was disabled. Now it should be fixed.
  • Worked on Pause again.
2018-04-28 2.0.0-β8 Yet another β-version. While working on the sync issue we had a closer look at Pause leading to some further improvements:
  • We have the impression that the remaining quirks can as well be observed with the standard DirectSound output. Anyway, you shouldn't hit the Pause button too frequent with no time left in between.
  • While looking at Pause we came through another obstacle: Disconnect when Pause. This feature was fully implemented all the time but was disabled because it didn't work with Double Buffered mode we're focussed on these days. With this mode and the option disabled the plug-in got immediatly stucked when un-pausing, i.e. the plug-in's IAudioClient seemed not to start again after having been stopped. This morning we had the right idea to finally resolve the issue: When in Double Buffered mode it's not sufficient to just stop the IAudioClient but it also needs to be reset. Hence the Disconnect when Pause feature is back again (also when in Double Buffered mode, i.e. Pulled Exclusive mode):
2018-04-26 2.0.0-β7 Needed another β-version because we've resolved a subtle synchronization issue: With this version the plug-in defers applying commands like Pause or Flush to be in sync with a playback cycle.
2018-04-23 2.0.0-β6
  • Implemented Bit Depth conversions:
  • In case you try to convert to a format not supported by your device you might get an error like

    When getting such an error you should cross check Configuration → Explore.
  • This might become v2.0.0.
  • Our further plans are
    • v2.1.0:  volume control, and
    • v2.2.0:  gapless playback.
2018-04-22 2.0.0-β5
  • Our preferred mode using this plug-in is double buffered, i.e. exclusive pulled. With this mode we sometimes observed that the plug-in got stucked. As a source of this strange behaviour we identified an underflow of the plug-in's buffer.
  • Our solution is in such a case sending silence to WASAPI instead of reading from the plug-in's buffer and reporting the incident by means of Dropout counters under Configure → Monitor:
  • A rule of thumb for configuring the plug-in: Make the buffer as small as possible but not that small that dropouts occur.
  • Introduced preprocessing this WEB page by means of the m4 macro processor allowing for a much more flexible way of editing.
  • From the
  • From the the Lovely Parasite's  forum:
  • Who are those people prefering inferior products just for political reasons? Obviously they like being replaced by an uncivilized "people" with an IQ of about 70. Anyway, we're not.
  • We doubt that people attracted by the Lovely Parasite  know what WASAPI really is. It could be that the Lovely Parasite  itself does not. We're convinced that they're satisfied by anything labelled "WASAPI" without asking any further question what's below the hoot. They shood stick with DS, really:
2018-04-20 2.0.0-β4 The user already mentioned notified us by PM that selecting a device hadn't worked as expected. This preview release fixes this (silly) bug. Many thanks again Ralf!
  • We've uploaded the (hopefully) fixed version 180412-1003 of the latest GTK runtime.
  • The reason the prior attempt was broken was that under the hood of remaining fully binary compatible the good people from the GTK team created a dependency to libfribidi-0.dll we'd not packaged.
  • In case you're interested in what the unsusual version numbers mean: They are constructed from the latest time stamp on MSYS2 of all files making up a complete runtime.
  • You can view the real versions by means of About → Versions. As far as we can see this time libgtk hasn't changed at all and libglib has a minor (but incompatible!) change from 2.56.0 up to 2.56.1:
  • We're now a step away from DepenencyWalker we once used to determine the DLLs needed (a tedious work we thought we're doing once and for all time) and started to create a shell script determining depencencies automatically by means of the commands strings in combination with grep (instead of DepenencyWalker).
  • Thanks again Ralf!
  • A user notified us by PM that the latest GTK runtime published on SourceForge is broken (it's not available any longer). Many thanks go out to Ralf!
  • For now you should revert to the prior version 180403-0917 or stick to the expert approach.
  • Sorry for any inconvenience.
2018-04-16 2.0.0-β3
  • Introduced options for defining the positions in Z-order of the Configuration and About dialogs, respectively.
  • Fixed saving the coordinates of dialogs in case they are not visible.
  • Changed some identifiers which may have broken your configuration. Please double check.
2018-04-12 2.2.0-β2 The second preview of what you might expect to come:
2018-04-11   We just noticed that on 2018-04-10, 04:19, the following new thread appeared at the WA forum:
Might be a fan of us but please note that this message is not ours. We don't post at the WA forum for years now.
Anyway, we know at least one Lovely Parasite  who likes tricking users into reporting to him and not to the plug-in's author:
2018-04-08 2.0.0-β1
  • We're back again: This is a preview of what you might expect to come. It's re-written from scratch with several improvements, hence we called it New Technology (NT). It's our attempt getting rid of annoying nasty Parasites  because we assume that those Parasites  are silly coders just being able to do some silly native win32 GUI coding based on drawn dialogs created with the help of some resource editor and hence we no longer provide a resource file.
  • This NT version is superior to any prior version by any means and does let any prior version look just like a silly prototype:
    • Exclusive pulled (i.e. double bufferered) playback is fully supported.
    • In case of pushed playback a periodic timer may be utilized. This allows for a wonderful symmetric solution compared to pulled playback where no timer is needed at all and playback is triggered in high accuracy by the device itself.
    • Initialization of any resource is deferred until it actually is needed. This way the plug-in's footprint at Winamp start-up time is the lowest possible, i.e. you will not notice whether it is installed.
    • Avoided any instance of busy waiting. In any attempt to fall back on it substituted it by thread synchronization means, i.e. WaitFor[Single/Multiple]Object[s]()/SetEvent() or g_cond_wait()/g_cond_signal() functions, respectively.
  • The GUI (i.e. the Configuration and About dialogs) were made from the great GTK+ toolkit.
  • You might fear that building on Gtk+ might pose some overhead compared to a native Windows implementation:
    • This is, of course, true.
    • But you should note that this is constraint to GUI/configuration and not to playback.
    • As long as you don't make use of the GUI there is no difference to a plain Windows WASAPI implementation. WASAPI is, of course, 100% Windows and nothing else.
    • Loading the GTK+ DLLs in a Winamp session is deferred until the Config or About buttons, respectively, are hit for the first time. To give an impression on the overhead of loading the GTK+ DLLs we display a wait cursor during the time it takes. (Be warned and be patient, especially when GTK+ has to be loaded after re-booting your system!) Once the DLLs required for GTK+ are loaded there is no measurable difference between GTK+ and a native Windows GUI.
    • Last but not least please remember the above note: This was the perfect opportunity for us to dive into the world of GTK+ programming. The result is more than satisfying.
  • This preview has the following limitations:
    • Format conversions (i.e. monto to stereo and bit depth conversions) are not implemented yet.
    • Volume control is not implemented yet.
    • Gapless playback is not implemented yet.
    • The documentation is not fully updated yet. (Updating might continue during the next days.) The documentation of previous versions is available here.
2018-02-16   Updated section Some Additional Notes Regarding the Lovely Parasite .
2017-04-27   As a sort of side project to out_yasapi we've created milkdrop2-compile:
2017-01-10   Added a political statement to the top of this page:
Nanos gigantum humeris insidentes: This project is dedicated to my European heritage. It is strictly to be understood as a statement against the "sweet" liberal lie of "multiculturalism" which is going to destroy Europe as we know it, in particular against the Merkel regime selling out Europe for nothing as we watch.
2016-11-10   To all you great people out there in the US: Thank you for electing Donald Trump!
2016-08-11   Just recently it came to our attention that a creature calling itself "DrO" (update 2018-04-08: according to the silly "one world" ideology ruling the so called "western world" it is just a "human being" without any individual properties discriminating it from others, just like an ant in a bath full of infinite many undistinguishible ants; you shouldn't have any doubt that in a literal sense it is "equal" to you and me by any means, just like in liberté, égalité, fraternité advertises a silly and buggy clone of this plug-in with just a few lines of code errornous changed (out of about 20.000 and his name added to the About box) he advertises under the name of Not So YASAPI Output Plug-in. Be careful and get not mixed up! The original YASAPI plug-in indeed comes from this site and SourceForge (as usual!) Luckily and thanks to the GPL3 the "author" of this silly clone had to leave the original copyright notice and the reference to this site intact!
2016-08-06 1.7.25
  • Parameterized the configure script that it may be useful for others as well (cf. the new section Compiling YASAPI from Source below). It now supportes the "./configure && make" cycle well known from UNIX/LINUX systems.
  • Fixed the error introduced with the prior version that YASAPI does not play in pull mode (as reported to the WA forum)
2016-07-30 1.7.24
  • Updated my build machine from Vista to Windows 7 (good bye Vista users).
  • Hence the new version is build using MSVC 11 / Windows SDK v7.1A (instead of the respective MSVC 10 / Windows SDK v7.0A under Vista.)
  • Dropped the SSE2 versions because by using MSVC 11 they make no sense any longer.
  • As usual, some code clean-up.
2016-07-19 1.7.23  
2016-07-15 1.7.22  
2016-07-12 1.7.21  
2016-07-08 1.7.20  
2016-07-05 1.7.19  
2016-07-03 1.7.18
  • Some final code clean-up before moving on.
  • Development ist stalled again.
2016-07-03 1.7.18
  • Some final code clean-up before moving on.
  • Development ist stalled again.
2016-07-30 1.7.17 Added the following personal statement to the About dialog and to the projects home page at http://out-yasapi.sourceforge.net/:
2016-07-30 1.7.15 Fixed several bugs regarding the implementation of the device specific option Extend to 24 Bit. This option is apperently not equivalent to Winamp → Options → Preferences → Playback → Playback → Allow 24bit because the latter reduces bit deps to 16 bit if un-checked otherwise to 24 bit. Bit depth is never extended to 24 bit. YASAPI extends bit depth to 24 bit those enabling playback on devices which does support 24 bit WASAPI playback but not 16 bit WASAPI playback.
2016-06-27 1.7.10 Added a device specific option in order to define gwhether YASAPI should promote 8/16 bit input to 24 bit. This is not greally necessary because the same effect can be achieved by genabeling Winamp → Options → Preferences → Playback g→ Playback → Allow 24bit but is provided on user request
2016-06-23 1.7.4
  • Factored out a framework for simialr plug-ins.
  • Connect to the device before continue playing after flush when in underflow.
2016-06-21 1.7.1 Improved migrating the plug-in from an un-plugged default device to the new default device when playing.
2016-06-20 1.7.0 (Limited) support for un-plugging the default device (as configured via System control) when playing.
2016-06-19 1.6.14
  • Disconnect on pause and undeflow when option Disconnect is choosen.
  • Removed timer for disconnecting gapless sessions because it is not needed any longer.
  • Fixed crashing of the configuration dialog in case the device selected in the previous session has meanwhile become invalid.
2016-06-14 1.6.11 Fixed combining pause with flush (skip).
2016-06-13 1.6.9
  • For gapless mode it is configurable after which time interval the connection should be released when in idle state.
  • Reworked the tracing facilities of the debug version.
2016-06-11 1.6.8 For the debug version it may be configured that the trace is written to a file in the AppData/Winamp/Plugin directory rather then dispalying it in a console.
2016-06-12 1.6.7 In gapless mode, when a playlist ends the device is not released. It is waiting for the next track to start. This situation is un-distinguishable from an ordinary underflow situation and hence playback ends in an undeflow state. This may cause trouble when in such a situation the user decides to change the output plugin (via configuration). This new version applys to exact this situation: If in case the user changes the output plugin and this plugin is found in an underflow state this plugin is closed (and hence the device released).
2016-06-12 1.6.6 Fixes regarding gapless playback.
2016-06-12 1.6.5
  • Stopping player when Winamp closes and not already stopped (needed for gapless mode).
  • Guarding against locking zero sized device buffers.
  • Reworked About dialog.
2016-05-29 1.6.4 Added a common option in order to define whether 4, 6, or 8 channels should be interpreted as qadrophnic (3.1), 5.1, or 7.1 (disabled) or sorround (3.1 sorround), 5.1 sorround, or 7.1 sorround (enabled), respectively.
2016-05-26 1.6.3
  • Fixed AUDCLNT_E_BUFFER_SIZE_ERROR appearing in eclusive/pull mode.
  • Fixed a potential forever-loop which may have appeared at the end of a track.
  • Fixed crashing as client of the WinampMatrixMixer output plugin.
2016-05-22 1.6.0
  • Gapless playback.
  • A common option for switching on/off gapless playback (disabled by default).
  • A device option for choosing whether the time offset for gapless playback is maintained as a 64-bit integer value (representing the playback position) or as a 64-bit floating point value (representing the quotient taken from the playback position and a frequency). For a deeper understanding regarding position and frequency values you may refer to the documentation of the IAudioClock::GetPosition() and IAudioClock::GetFrequency() methods. We feel that as long as a constant frequency value can be assumed choosing the time offset as beeing maintained as a 64-bit integer value is preferable.
  • A debug version for SSE2.
2016-05-17 1.5.4 Solved the dead-lock caused by saving the configuration.
2016-05-17 1.5.3 Improved dealing with draining the ring buffer and end of track (eot).
2016-05-16 1.5.0
  • The Default Device is listed in the respective configuration dialog's drop down box as an option to choose.
  • In case the Default Device is choosen from the drop down box (and saved),
    • the configuration is saved for the physical device which was configured at the time (configuration time) as Default Device from Window's System Control when the configuration was loaded to the dialog,
    • each time a new track starts, the physical device configured at this time (play time) as Default Device from Window's System Control is used to play the track (please note that this device may differ from the one configured at configuration time).
Please note that this is a complete re-write. Everything was thrown into peaces, something into larger building blocks and something into dust. The larger building blocks, which greatly remained intakt, could be re-used. The dust had to be thrown away and substituted by a new development. Please be careful in using this new version, thoroughly test it and re-configure it, if needed.
2016-04-09 1.0.7 In order to have YASAPI in a well defined state from the very first beginning, reset the IAudioClient interface at start-up.
2016-01-13 1.0.6
  • Detect end of track by respective "isplaying" request.
  • Fixed bug regarding synchronization of Share Mode and Strategy options.
2016-01-09 1.0.0
2016-01-03 1.16.0
  • Guarded against writing when paused.
  • Stopping audio client when underflow.
  • From the configuration dialog, dropped the device list page in favour of a combobox on top of the dialog.
  • Slightly adapted default values.
2015-12-21 1.16.5 Brought back, as an option, a call to IAudioClient::IsFormatSupported which is disabled by default.
2015-12-10 1.14.1 Increased default ring buffer size to 2.5.
2015-12-08 1.14.0
  • Introduced an (by default enabled) option "Write Block" that in case the plugin's "write" method delivers more data than actually could be written to the ring buffer it should block and wait until enough data are consumed from it rather then returning immediately.
  • For automatic mode, removed restrictions for switching from exclusive to shared mode.
2015-12-04 1.11.0
  • Reorganized the configuration dialog:
    • Focused again on the most important two (per device) parameters "Mode" (share/exclusive) and "Strategy" (push/pull).
    • Duplicated those two parameters from the "Device Options" page to the dialog's top-region.
    • Moved the former top-region parameters to a new "General" tab-control page.
    • Added a "Store" button with similar functionality as the "OK" button except that it doesn't close the dialog.
  • Fixed several bugs.
2015-11-29 1.10.0
  • Reorganized configuration of device period.
  • Added progess bars to the configuration dialog in order to visualize the load of the ring and the shared buffers.
  • Added an option for dis-/enabling the visualization.
  • Added an (experimental) function for balancing the shared buffer.
  • Added some more tracing to the debug version.
  • Split the verbose debugging into verbose level 1 ond and level 2 (even more verbose).
2015-11-23 1.9.1
  • Added an option for configuring whether calculation of the buffer sizes should be based on the default or on the minimum device period as proposed by WASAPI. Made default device period the default. So long the calculation was silently based on the minimum device period.
  • Added tooltips to the configuration dialog's controls.
2015-11-22 1.9.0
  • Complete re-write based on a new architecture. The basic idea is to serialize all requests and dispatch them into just one worker thread. In particular the serialization takes into account asynchronous requests resulting from the WASAPI device.
  • Round up ("ceil") the size of the ring buffer to the next multiple of Winamp's packet size (576 samples).
  • Special treatment of double buffering, i.e. pull in exclusive mode.
  • Additional options to configure the debug version.
Note:  You should re-configure at least the buffer sizes. As a rule of thumb all buffer sizes should be 1.0 except the ring buffer's size which should be just a small amount greater then 1.0.
  • Improved thread synchronization during start-up.
  • Fixed a bug regarding recovery from error AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED of the IAudioClient::Initialize() method.
2015-10-31 1.8.2
2015-10-30 1.8.1 New share mode "automatic" which is similar to exclusive except that it falls back to shared in case exclusive fails.
2015-10-29 1.8.0
  • Improved synchronization with visualizations and video because of
    • corrected calculation of max latency and
    • corrected calculation of "written time".
  • Dropped "written time" options.
  • Dropped the call to IAudioClient::IsFormatSupported().
  • New device specific options "Auto Convert PCM" and "SRC Default Quality". These Options are only available in shared mode. They correspond to the AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM and flags, respectively, of the IAudioClient::Initialize() method (regarding the AUDCLNT_STREAMFLAGS_SRC_DEFAULT_QUALITY flag cf. also here).
2015-10-26 1.7.1
  • Automatic re-sampling in shared mode seems to work now.
  • Added an "Exit Winamp" option to the error message dialog box.
2015-10-26 1.7.0
  • Support for multiple devices.
  • Configuration options per device.
  • Various fixes.
Note: Prior configuration for the default device may be lost. Please re-configure.
2015-10-03 1.6.1 Corrected a silly bug in testing for share mode.
2015-10-03 1.6.0 Add AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM flag when in shared mode (doesn't have any effect on Vista).
2015-02-14 1.5.0
  • Utilization of the IAudioClock interface instead of the GetTickCount() or the timeGetTime() functions for reporting the elapsed time to Winamp.
  • Option for controlling whether "written time" should be calculated.
2015-01-30 1.4.0
  • Option for treating mono as stero (default switched on).
  • New default options for buffer configuration.
  • Some fixes.
2015-01-25 1.3.0
  • Support for pull strategy.
  • Support for volume control.
2015-01-24 0.2.1
  • Component Object Model (COM) error messages are displayed with the file and the line number where they occur.
  • Compiled with shared "MSVCR110.DLL" (instead of static as before).
2015-01-24 0.2.0
  • Improved configuration for buffer sizes.
  • Provided a SSE2 version.
  • Compiled with the C compiler from "Visual Studio 10 Express" (instead of "Visual Studio 9 Express" as before).
2015-01-23 0.1.0 Initial release.

2. Introduction

According to Microsoft:

The Core Audio APIs were introduced in Windows Vista. This is a new set of user-mode audio components provides client applications with improved audio capabilities. These capabilities include the following:

Of special interest is that there is an exclusive mode for rendering audio, i.e. there is a mode where an application has exclusive access to the audio device without being disturbed by third parties.

The aim of the YASAPI plug-in is to make the WASAPI exclusive mode for audio rendering available to the users of Winamp.

The name of the plug-in was choosen because there are already at least two WASAPI output plug-in for Winamp:

3. Sequence Diagram

The following sequence diagram taken from the documentation v0.1 (describing to some extend YASAPI/NT v2.2-β5) was created using the impressive plantuml tool.

Note:    In case you know the "official" UML way to model threads please drop us a line (pbelkner@snafu.de.)

4. Installation

Installation is as easy as downloading and running the latest NSIS installer from the project's download page.

Even if the plug-in runs without any further Configuration (not very likely) you may wish to configure it. In order to enable configuration you need some GTK runtime. You have two choices to make the plug-in familiar with a GTK runtime:

  1. The easy way:
  2. The expert way:

5. Implementation

There are two sides the YASAPI plug-in has to take into account:

The implementation on the WASAPI side follows along the lines of an example provided by Microsoft. The startegy shown in this example is not only applicable for shared mode streams but also for exclusive mode ones, i.e. not the share mode should be emphasized but what is known as the push model. There is also an example demonstrating the pull model in conjunction with the exclusive mode. In that sence there are four strategies:

The YASAPI plug-in implements the first two strategies, i.e. the ones based on the push model.

The push model, in principle, works as follows:

  1. Query the size of the buffer shared with the audio device.
  2. Fill in completety the buffer shared with the audio device.
  3. Start playing.
  4. Loop until the track is played:
    1. Sleep half of the time corresponding to the size of the buffer shared with the audio device.
    2. Into the buffer shared with the audio device, fill in the gap which was growing free by playing during sleep.
  5. Sleep until the possibly remaining filled rest of the buffer shared with the audio device was played.
  6. Stop playing.

But the YASAPI plug-in not only has to take into account the WASAPI side (the loop consisting of sleeping and writing to the audio device) but also the Winamp side because Winamp provides the audio samples which should be played in an completely unpredictable way.

The YASAPI plug-in decouples the two sides by means of a ring or circular buffer. That way,

According to step 2 of the push model sketched above, it shoud become clear that the ring buffer should be at least as large (or larger) as the buffer the plug-in's WASAPI component shares with the audio device.

6. Configuration

The YASAPI/NT plug-in comes with a configuration dialog which described in the following. The configuration dialog's top region presents the most important parameters:

Below the top region you find a notebook control consisting of five pages:

The notebook control's first page labelled Common looks as follows:

On the next page labeled WASAPI there are the following per device options:

On the next page labeled YASAPI/NT there are the following per device options:

The next page labeled Monitor looks the following:

The final page labeled Explore looks the following:

From the above sketch of the push model it shold be clear that the following relation holds (which is enforced by the configuration dialog):

minimum size of the buffer shared with the device (provided by WASAPI) <= size of buffer shared with the device <= number of samples in the ring buffer before start playing <= size of ring buffer
As a rule of thumb all buffer sizes should be 1.0 except the ring buffer's size which should be just a small amount greater then 1.0.

Please note that no option takes effect before hitting the OK button.

7. References

Just to name a few we'd like to thank (in no particular order)

8. A Message Silently Disappearing from the Winamp Forums

The following message posted by me to the top-level (sticky) thread Winamp News in forum the Winamp Discussion forum silently disappeared without any comment:

Dear DJ Egg,

I'm not certain whether you are the right person to address my reqest.. I'm not even certain about who rules this forum. My impression is that you are the only one "official" left (i.e. one with a contract to the owners of Winamp). All the rest including this forum's moderators seem to be volunteers.

As you may have noticed, since some time I have a conflict with some of the former contractors of Winamp, "DrO", regarding the question of intellectual property. As it turns out, this former contractor, "DrO", disrespects intellectual property. He advertises a product he calls "Not So YASAPI Output Plug-in v1.0 Beta" which is a close to 100% clone of YASAPI (cf. here for details).

As it turns out that at the blog of "DrO" some of his fanboys comment we know by their nicknames are frequent posters of this forum, among them some Pawel:

Could you please investigate whether this Pawel is identical to this forum's moderator with the same nickname and in case it turns out to be true fire him from his job as a moderator?

Thank you in advance and best regards,


9. Some Additional Notes Regarding the Lovely Parasite 

On his blog the Lovely Parasite  claims:

That's of course true. And I'm the last one to have ever told something different. But if doing so, changing just a few lines of code out of about 20.000 just in order to rectify putting his name on the product I consider a clear case of plagiarism:

For further details refer to the Winamp forum.

The Lovely Parasite's  further explanations are simply laughable:

Darren, it's not your WASAPI plug-in, it's mine. Even with that little changes you've made you've perfectly demonstrated that you don't have the slightest idea on how this (my) plug-in is supposed to work and you've managed introducing a major bug into the configuration.

Update 2018-02-16:

Meanwhile the Lovely Parasite  on his web site confirms that his buggy GPL clone is just a fake and that he's distributing (by violating YASAPI's license) a non GPL version to registered so called "beta testers":

As it seems, this way he (the "Hero Member" , what kind of people are attracted by such a spast?) likes to trick users into registering.

Disclaimer: Mit Urteil vom 12. Mai 1998 − 312 O 85/98 − “Haftung für Links” hat das Landgericht (LG) Hamburg entschieden, daß man durch das Setzen eines Links, die Inhalte der gelinkten Seite ggf. mit zu verantworten hat. Dies kann − so das LG − nur dadurch verhindert werden, daß man sich ausdrücklich von diesen Inhalten distanziert. Hiermit distanzieren wir uns ausdrücklich von den verlinkten bzw. zitierten oder als Zitat übernommenen Seiten.