• 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?
• In order to comply with their “policy” we’re not any longer going to let host this page by Sourceforge but have copied it already to http://out-yasapi.sourceforge.net/.
• Within a few days we’re going to remove it from Sourceforge.
• 2020-06-06 − Because we’re not willing to follow the orders by Sourceforge this project has to leave. As soon as there’s a domain pbelkner.de available expect a revival of the project. Most likely
  • this page will re-appear at ”http://www.pbelkner.de/software/web/out-yasapi/“, and
  • the project’s releases at ”http://www.pbelkner.de/software/frs/out-yasapi/out_yasapi-2a/“.

• 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.

• 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.

• Merkel, it's time to go: Angela Merkel seen shaking uncontrollably for second time in nine days.
• There are rumors that for years(!) Merkel is plagued by Parkinson's disease and at least never shoud have been candidate for Chancellor in the 2017 elections (watch her 2017 in Mexico.)
• Update 2019-06-29: Red Ice TV: Merkel Really IS Sick, Shaking Uncontrollably AGAIN.
• Update 2019-07-10: Angela Merkel shaking for third time in as many weeks.

• 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)... 5.39.58.66
  Connecting to download.nullsoft.com (download.nullsoft.com)|5.39.58.66|: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.

• 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-β₁, v2.3.3-β₂, v2.3.3-β₃, and v2.3.3-β₄ needed for respective communications):
  • The error code returned was AUDCLNT_E_UNSUPPORTED_FORMAT, an error code
    • not documented  for IAudioClient::Initialize, but indeed
    • documented  for IAudioClient::IsFormatSupported.
  • 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.

• 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.

• Dr. Ludwig: This is Germany (update 2019-09-24: seems to have vaporized, try this link.)
• Dr. Ludwig: German castles and palaces (update 2019-09-24: seems to have vaporized, try this link.)

• We're proud to announce that finally v2.3.0 has been released.
• It's essentially the same as v2.3.0-β₁₃.
• 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.

• 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)

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.
  

• 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.)

• 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*

• 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.)

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.)

• As announced with v2.2.0-β₅ 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-β₂: gapless playback, and
  • v2.3.0-β₃: 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
  

• The Lovely Parasite  has fresh promises
  
• And of course, he wants your shekels just based on empty promises:
  

• 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-β₁ 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
  

• 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.

• 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.

• Allmost the same as v2.1.0-β₆ except some code cleanup.
• Next steps might be:
  • v2.2.0-β₁  Reorganization of YASAPI/NT's buffer in order that it better suits gapless playback.
  • v2.2.0-β₂  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:
   

• Fixed a subtle bug with Dithering.
• Restructured time reporting functions, i.e. getwrittentime() and getoutputtime().

• 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.

• Introduced support of Volume Control for Exclusive Mode playback due to WASAPI interface IAudioEndpointVolume (once scheduled as v2.1.0-β₃).
• 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.

• The next regular update once scheduled as v2.1.0-β₂ 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.

• 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-β₁+ 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.

• 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:
  

• Essentially the same as v2.0.0-β₁0 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-β₁:  Volume Control by means of software provided by YASAPI/NT,
  • v2.1.0-β₂:  Volume Control for Shared Mode playback supporting the WASAPI ISimpleAudioVolume interface, and
  • v2.1.0-β₃:  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.)

• Just discovered that the combo box advertised with v2.0.0-β₆ was disabled. Now it should be fixed.
• Worked on Pause again.

• 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):
  

• 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.

• 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:
  

• 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.

• 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.

• Added mono to stereo conversion.
• Slightly changed the semantics of the Cancel button.

• 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.

• https://sourceforge.net/projects/milkdrop2-compile/
• https://sourceforge.net/projects/milkdrop2-compile/files/milkdrop2-compile/

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.

• Added the section A Message Silently Disappearing from the Winamp Forums to this documentattion.
• Added the section Some Additional Notes Regarding the Lovely Parasite  to this documentation.

• 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)

• 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.

• Some final code clean-up before moving on.
• Development ist stalled again.

• Some final code clean-up before moving on.
• Development ist stalled again.

PLEASE NOTE THAT THIS PROJECT IS AN EXPERIMENTAL RATHER THEN AN INDUSTRIAL STRENGTH EFFORT. THIS PROJECT IS NOT FOR YOU. IT IS FOR ME IN ORDER TO LEARN SOMETHING. IF THERE IS SOMETHING ALONG THE WAY I CAN DO FOR YOU THAT'S GREAT!

• Factored out a framework for simialr plug-ins.
• Connect to the device before continue playing after flush when in underflow.

• 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.

• 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.

• Stopping player when Winamp closes and not already stopped (needed for gapless mode).
• Guarding against locking zero sized device buffers.
• Reworked About dialog.

• 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.

• 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.

• 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).

• Detect end of track by respective "isplaying" request.
• Fixed bug regarding synchronization of Share Mode and Strategy options.

• Some minor code clean-up.
• Further development is stalled because according to the Winamp team they have developed a native WASAPI output plugin: "Benski has coded a new out_wasapi plug-in" and "itll probably be included with 5.8 beta"'.

• 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.

• 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.

• 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.

• 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).

• 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.

• 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.

• Improved thread synchronization during start-up.
• Fixed a bug regarding recovery from error AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED of the IAudioClient::Initialize() method.

• Implemented recovery from error AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED of the IAudioClient::Initialize() method (cf. remarks section from MSDN documentation).
• Added support for KSAUDIO_SPEAKER_7POINT1.

• 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).

• Automatic re-sampling in shared mode seems to work now.
• Added an "Exit Winamp" option to the error message dialog box.

• Support for multiple devices.
• Configuration options per device.
• Various fixes.

• 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.

• Option for treating mono as stero (default switched on).
• New default options for buffer configuration.
• Some fixes.

• Support for pull strategy.
• Support for volume control.

• 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).

• 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).