make an installer for the plugin and have it check for the existance and prompt to download the redist package if not there. i think there's already an nsis script/example that should be able to do it.

or implement your own new and delete (just map them to malloc and free) and that'll remove the dependancy.

Well. It's really does not hurt but it tells you that input plugin feeding data more intensely then it instructed to. So some data was thrown out of the playback queue. To simplify the explanation the input asks it's slave output plugin about how much data the output is ready to render but then it pushed way more data. Why to ask then!?

This was my first plugin for winamp and collected enough inaccuraties. That's sad the winamp works kind of hacky way. I'm in process of redesigning my plugin. This can take a time.

It's not just with yours, but it seems with all of the wasapi and openal plugins causes winamp to throw a "onpropertyvaluechange" notice on startup and on most audio changes like going into audio properties, or adjusting volume. I'm just wondering if others get similar errors, or if its just a issue with Windows 7.

Have not tried Windows 7 yet. Must be something changed dramatically but very unlikely i did something totally different from the example code by Microsoft.

"onpropertyvaluechange" notice should not pop up on startup or volume adjusting. Notification can't be triggered by volume as the volume controls have it's own notification thread. Startup can't trigger the notification because there is all stuff around that are new to plugin and they normally can't be reported as changed within a second the notification was enabled. Still i do use the "onpropertyvaluechange" message to simplify the debugging. Yea it may look gay for a moment but i do hope to make hot swap for output devices once.

You must be using some DSP/Effect plugin with winamp 5.572, do you? Most likely the double resampling happens. Bad bad thing. In real life you do not need anything except input and output plugins.
Pardon me, you are using SRS Audio Sandbox, right? Then it is not friendly for MAIKO v0.05 in terms of quality as was for MAIKO v0.03. Working on the issue.
Second, you are equipped with sound blaster live 24 bit, yes? You are my client then, the shared mode is a must for your card Set the shared mode to "24bit, 48000hz (Studio Quality)", disable the SRS plugin and you will be fine

The maiko still the early beta because:

for a v0.04 - 0.05 versions, if the input sample rate is equal to the output sample rate then it may have some quality issues in the corner cases. Working on the patch but this is not the easy thing because the qualitative processing is so complicated and have the lot of adaptive alternative pathes. For me the direct copy is the processing too and it should fit well into plugin design. The v0.03 had no issues with such copies but it had the issues with the buffering so the whole processor was rewritten... i'm working on the special cases quality issues now. At least it work for you and i'm happy about it.

in progress (expecting soon):
+ At last can select the device explicitly. WARNING! You need to stop the playback
first because those tread lockouts misteries needs some investigation!
+ Some work on configuration panel.
+ Experimenting on extra DirectSound renderer to have the ultimate all-in-one
output. You don't want to run it on WindowsXP yet.
wow..good..!
How soon ?

DirectSound renderer is in a serious delay. It's just an experiment anyway and i'm not sure it would not be just cutted off cause of bad mood. Too much to do things for wasting time on outdated feature. So far no one expressed the concern about the unified DS&WASAPI.

The simplified configuration panel will be in the next update just need to fix some odd quirks with GUI controls.. The complete configuration set would not be available until i decide on the mixer design.

I just tried the latest version of Maiko, and it's very good. I appreciate this work!!!

A 162 ms buffer in WASAPI has dramatically fewer (read: 0) dropouts than any size buffer (tried all the way up to 2000 ms) in DirectSound. I think DirectSound was good on Windows XP, but since it has to go through audiodg.exe on Vista/7, it's been choppy as heck for me.

What I noticed with DirectSound is that any significant activity in a VMware virtual machine would create terrible dropouts. This was observed across the board, regardless of what exactly was using DirectSound: foobar2000, Winamp, Mass Effect 2, or VMware itself (through ALSA emulation). But WASAPI bypasses the problem with audiodg.

mark007, I will give it a thought what can be done on the matter. Looks like just to use the development kit from windows 7 is not enough. Your case seems to be rare. And unfortunately I would not run the plugin in person on Windows 7 any soon. Stripped off most of logging after felt safe on Vista how ironic. Ok, I will try to get the log back and publish the debug version alongside the next release.

Would be very helpful to know does it crashing on motherboard build in codec also. I'm already aware of questionable behaviour for some laptop drivers.

Trying it at the moment (just found this thread).
Windows 7 x64
Focusrite Saffire pro 24
Winamp (latest version) @ 16-bits (don't think I should enable 24-bits because my mp3s are all ripped at 16)

It seems to be working OK. I don't really get the difference between WASAPI and directsound other than it is supposed to bypass Windows mixer. All I can tell is that it sounds louder (not something I needed really) and it still responds to the windows mixer.

mp3
For winamp & maiko combo you should definitely go 24 bit. It would reduce the rounding errors both input plugin and output. The mp3 by its nature have its sample representation in floating point, it's lossy format. The input plugin simply trancates the precision to 16 or 24 bit. Maiko converts it back to floating point for it's own processing needs.

OnPropertyValueChanged
That is not the error really but remains of the debugging code left. It says the device was reconfigured or somehow changed it's state. I'm aware of this and would silent the plugin next time. BTW are you curious about fact your card changing it's settings all randomly without your tinkering with control panels? Looks like sometimes Windows 7 really do something nasty by it's own will, surprise!

All I can tell is that it sounds louder
It is not sounds louder, it sound precisely right. DirectSound have it's own know how fighting the loudness war. Loudness war is the real scar of the modern audio industry. You want the audio playing bearable with crappy ear plugs in heavy city traffic, just make it loud, louder! DirectSound have no authority here you should compare to WASAPI exclusive mode plugins or ASIO plugins. And of course, DirectSound is not as much layered on XP as it is on Win7.

and it still responds to the windows mixer
That's intensional. Vista's audio stack is more clarified and clean compared to XP one. Once the data cooked right (Maiko case) windows mixer do copy through without any further processing applied. Except windows volume control which is bound to winamp own volume slider anyway. So practicaly it's like having upsampler & exlusive output combo without muting other applications. Figuratively i'm trying to knock two birds with one stone. Windows mixer still works at bare minimum with precomputed winamp data and awaiting for other applications to work cooperatively.

Great, thanks for explaining. Another question, will there be a way to be able to pan? That would make this the perfect plugin for me, as I am also trying ASIO plugins which also don't let me pan (and some don't even let me control volume)

No, i'm not excited with panning idea for many reasons. And not me only. That's why there is no panning slider on Winamp 5 skin. I'd highly recommend to balance the channels with hardware mixers instead of tinkering within every other software.

Just for the sake of every useless thing in this world, i'm planning the per channel volume control which is more obvious and easy to set an to understand and more compatible with multichannel setups. But in the first place there is a more urgent need to finalize the mixer design to actually support multichannel setups.

And not me only. That's why there is no panning slider on Winamp 5 skin.

that statement is wrong - it's generally called balance in Modern skins instead of panning (classic skins) and is generally part of the equaliser views instead of being a fixed part of the ui as with the classic skins. just saying to clarify things.

No, i'm not excited with panning idea for many reasons. And not me only. That's why there is no panning slider on Winamp 5 skin. I'd highly recommend to balance the channels with hardware mixers instead of tinkering within every other software.

Just for the sake of every useless thing in this world, i'm planning the per channel volume control which is more obvious and easy to set an to understand and more compatible with multichannel setups. But in the first place there is a more urgent need to finalize the mixer design to actually support multichannel setups.

I'm not using the modern skins for the sole reason that they don't include the pan option. I use that almost every day and I think it is important to have (specially for musicians and producers). If you ever plan on adding panning I might give this plugin another try, until then I'm sticking with ASIO, which provides the same features (also without panning)

For the ones kind of dissapointed with 0.07 i brought all the stable patches together. The version 0.08 is probably the most glitchless version up to date. MessageBox spamming was silenced along the way.