WASAPI Output Plugin 'Maiko' (VISTA & later only)

[kerimcem]

0.8 update thanks..
My problems continue .. sorry ..

[dstln]

Thanks much. I no longer get the popup unless I do something silly like change default sound output while winamp is running.

[SilverBird775]

Originally Posted by kerimcem

0.8 update thanks..
My problems continue .. sorry ..

Ha ha nasty boxy one Silenced ultimately 0.09

[kerimcem]

Originally Posted by SilverBird775

Ha ha nasty boxy one Silenced ultimately 0.09

thanks...Works Perfectly

[SilverBird775]

0.10
This version adressing the stability matter, tried almost all kind of files and input plugins i have. All is fine up to 5.1 audio. The 7 and 8 channel audio ummmm, you better do not try them yet, okay? Once again greatly improved video playback latency and completely reworked the seeking precision.

Oh well.. please stop the playback before changing something in control panel. I still do not worked out the understanding how to safely lock the playback thread without actually stopping\pausing the playback.

The rendering buffer can be set lower then default one but the main obstacle have to be my resampler that need some space to operate. Still need a lot of touch here to reduce the resampler latency which is wholy contribute to overall processing latency. The resampler does not contribute to plugin latency though. Other then this the whole plugin is virtually transparent. It do indeed transparent when the source sample rate and device shared mode sample rate are matching.

You need to understand the latencies correctly. Some of the latencies (like Maiko's own) are virtually transparent but they are limiting the minimum rendering buffer that can be safely used. You cannot set the buffer any lower then any latency reported by the log window. Doing this you are risking the audio underruns resulting in sound hicks and interrupts. One note though, the lower client buffer do not contribute to more precise video playback timings. Too big buffer (more then 500 ms) just wasting the memory because the MAIKO plugin buffer is secondary to Windows cross-appication mix buffer.

Yet another note. The plugin cannot and do not compute the input plugin latency, that one sometimes can be really high and also contributes to the minimum rendering buffer that can be safely used. This plugin provides the true seamless playback but to notice it you need the input plugin to provide the initial start up portion as soon as possible before the buffer completely drains out. The time of awaiting allowed is exactly the buffer size (adjustable in millisecons). When the buffer drains out of data the rendering engine will continue to fill the buffer with the silence awaiting for a first input plugin write transaction, so you still all safe.

Sorry for a twisted English. Have a nice day

[Dexter_prog]

Panning would be appreciated.

[Ryokurin]

Looks like it was updated today.

[2011 01 13][v 0.14]
* SSE2 optimizations.
* Lots of work on 7 and 8 channel routing. Some issues still exist.
! Low Frequency Emitter channel should work again. Yeah :-)
! Rare but serious bug in channel indexing discovered & fixed.
(Can be triggered on non STEREO and non 5.1 systems only)

[SilverBird775]

...and i'm happy to announce that most urgent issues was adressed and that tends me to believe exclusive mode support is the next hot issue.

Sorry Dexter_prog, i took my time and still does not change my mind about classical Panning. Per channel gain and routing table that is the sure thing for 2+ channel setups. Panning the legacy option can be turned on by occasion for a most scenario. More switches more bloated the software is. I'm quite happy with WINAMP modern skin where the panning option was placed along with another useless option, equalizer in just one place so i can safely ignore both. Panning is a natural part of DirectSound and comes for free. WASAPI is more clean, modern API and have no questionable functionality like panning build-in. You want me to reiterate the mistakes of the 8-bit stereo only sound blaster age? Nein.

[kerimcem]

Visualization don't work on 0.13 and 0.14 versions of WASAPI
pls fix it
pic
http://img341.imageshack.us/img341/1...ranalntsux.jpg
thanks silver..

[SilverBird775]

lol
kerimcem, believe it or not i did not noticed it. It seems to be the result of the very high internal latency. Resampler is fully responsible for this latency. The precision and latency could be balanced so the beat animation would work again. Yet i just can't get how to completely mask out this huge latency, the plugin overall works correct (to my understanding; it shows video but beat animation loose something at some point). If you want i could issue a quick patch with balanced precision for you because i'm really stressing the limits at the moment. If you find it better i will probably made it official then.

[kerimcem]

thank you.If you have free time, pls make a patch about this.

[SilverBird775]

kerimcem

We'll see how this work.

[kerimcem]

it works! so thanks ..

[alicans]

so thanks!!1 im using maiko everytime)

[howisya]

Originally Posted by SilverBird775

kerimcem

We'll see how this work.

thanks. this also fixed the mono wav playback issue we talked about in the other thread.

[howisya]

...however, mono mp3 files still echo like wav files did.

[SilverBird775]

Oh, that's the news then. Please private message me the link to sample files with such a behaviour. Mind you it could be the decoder issue as well. Testing the playback through official DirectSound plugin and/or output alternatives could also indicate the problem. For example there is massive channel numerating problem with Nullsoft DirectShow decoder. It's wrongly assume not mono files to be stereo only and so it fails on multichannel files.

[SilverBird775]

@howisya: False alarm.

@all:Check out the homepage on Jan 30 for a most important update since the first beta! Still cant believe i'm finally fixed the very complex latency bug. You know last day i was just like Paolo Villaggio's robinson with coconut: ouch, it supposed to be screwed off like a cap not cracked!

[howisya]

Originally Posted by howisya

...however, mono mp3 files still echo like wav files did.

my mistake earlier

[kerimcem]

v.15 dont work

[SilverBird775]

The buffering is changed. Or better, it was finally fixed. Now you should keep the WASAPI client buffer higher then MAIKO buffer.

You may adjust the client buffer while player is stopped then push Client reload button


For example, push play button (to initialize the input stream, so we can get latency estimation), then go to controls and look for numbers:

Input stream:
80 bit float PCM encoding in 2.0 (Stereo) setup. 44100Hz rate
MAIKO buffer: 15070 samples (341723 µs) with up to 341723 µs latency

Output stream:
32 bit float PCM encoding in 2.0 (Stereo) setup. 96000Hz rate
WASAPI client buffer: 61440 samples (640000 µs)
WASAPI client latency: 10666 µs
WASAPI cross-application mix latency: 10000 µs

Plugin latency reported to Winamp: 353 ms

341723 µs (342ms) is lower then 640000 µs (640ms). Not much buffer protection space here, but it works.
Watch out for a shocking 353ms plugin latency, you cannot possibly go lower then this, it simply would not start. If you used a custom latency before, just put 0 as your new latency to get the new default (640ms) or put your number here.

Edit:
This latency is where the buffer is sucking in data for a filter, it accumulates data and does not necessary output something. That is why you need to fill it up enough so it may output something filtered. While it accumulates, it lags - thus why it is the latency. latency = lag. The winamp could compensate the lag so it lip-sinc the video to actual audio.

[kerimcem]

Originally Posted by SilverBird775

The buffering is changed. Or better, it was finally fixed. Now you should keep the WASAPI client buffer higher then MAIKO buffer.

You may adjust the client buffer while player is stopped then push Client reload button


For example, push play button (to initialize the input stream, so we can get latency estimation), then go to controls and look for numbers:

Input stream:
80 bit float PCM encoding in 2.0 (Stereo) setup. 44100Hz rate
MAIKO buffer: 15070 samples (341723 µs) with up to 341723 µs latency

Output stream:
32 bit float PCM encoding in 2.0 (Stereo) setup. 96000Hz rate
WASAPI client buffer: 61440 samples (640000 µs)
WASAPI client latency: 10666 µs
WASAPI cross-application mix latency: 10000 µs

Plugin latency reported to Winamp: 353 ms

341723 µs (342ms) is lower then 640000 µs (640ms). Not much buffer protection space here, but it works.
Watch out for a shocking 353ms plugin latency, you cannot possibly go lower then this, it simply would not start. If you used a custom latency before, just put 0 as your new latency to get the new default (640ms) or put your number here.

Edit:
This latency is where the buffer is sucking in data for a filter, it accumulates data and does not necessary output something. That is why you need to fill it up enough so it may output something filtered. While it accumulates, it lags - thus why it is the latency. latency = lag. The winamp could compensate the lag so it lip-sinc the video to actual audio.

it doesnt work on "640", but it worked on "800"

[SilverBird775]

You may observe the buffer bar. It shows how the data drains out from WASAPI Client buffer in realtime, then the mixer burst in a lot of data from filter. Looks like a heartbeat. If it drops to zero, there would be glitch (just silent pause really, no data for audiocard - no sound).

[kerimcem]

my buffer is between 15% and 40%.Has it create problem? beforetime it was 90% or %100(v.14.1)

[SilverBird775]

Please post your Status log (like i did in my example) while playing something so i can make recommendations.

For a very quick math you can choose MAIKO buffer * 2, some round number close to it, i think it is ok.
40-70% buffer occupation is good. 15%-40% is critical, it may glitch on heavy system load when the processor is busy.

When you understand the numbers you will see it it very easy to contol buffering.

[kerimcem]

Originally Posted by SilverBird775

Please post your Status log (like i did in my example) while playing something so i can make recommendations.

For a very quick math you can choose MAIKO buffer * 2, some round number close to it, i think it is ok.
40-70% buffer occupation is good. 15%-40% is critical, it may glitch on heavy system load when the processor is busy.

When you understand the numbers you will see it it very easy to contol buffering.

thanks silver..I dont know so technic info.I returned back to 14.1 .Its buffer between 95%-100%

[Ryokurin]

just try bigger numbers in the client buffer size. I was like you and it worked at 800 but the buffer was low, so I increased it a couple of times to 1200 and it's within the 40-70% range.

[SilverBird775]

Exactly.

Yours configurations seems different from mine. I checked all my audio cards, 640ms worked fine. Okay no problem then i will bump up the default, probably up to 1280ms.

0.14.2 and earlier suffered from the write function lock-ups (which sometimes caused jerky video) and masked out the huge resampler latency. better the quality - bigger the filters, bigger the filters - bigger the latency that is. Yes, before i pushed the buffer 100% full thanks to amazingly creative buffering technics. Unfortunately the beat animation was especially sensitive to unexplained timing black outs. Those timing blackouts leaked like a holey barrage everywhere, video, animation.

I tried really hard and there is no way around. Now the winamp is aware of delays and compensate it. This is also means the writing lock-ups is a big no-no. The good thing now i have two years proved overrun protection :-D.

Could not say for sure what would be next, either custom controls for mixer or exclusive mode, it depends on my trials experience of both directions. Quality tweaks as usual.

Thank you for response guys, i learn from it.

[VipZ]

Thanks for the awesome output plugin, I am not sure this is a flaw of Winamp as it occurs with the default output as well (With different error). When I have Winamp open and then play movie which bitstreams to my AVR, Winamp crashes with a dialog saying RenderDisconnectCallback, I use audio over HDMI at 5.1 96kHz/24bit. I have to close Winamp before starting bitstreaming to avoid this crash.

Let me know if I can do anything to help if you are able to look into this.

[kerimcem]

2011 01 30][v 0.16]
* Tweaks to make plugin more friendly to Mass-user.
* Changed a way for default mono->stereo mapping, double now instead of
correct matrixing. Naive math VS Science what a tough choice!

[2011 01 26][v 0.15]
* Major code revision.

v.16 working perfect thanks silver.

[SilverBird775]

0.16 - tiny update!


VipZ

Thank you for sharing your experience.
Indeed the RenderDisconnectCallback message needs to be explaned a bit. It say the maiko is aware of the selected device was hot-unplugged, that is the native feature of Vista. I could not reverse the unplugging process but in theory i can properly shut down the playback or redirect the playback to the next default device. That is just a theory, the winamp never meant to do such a thing. The playback is complex and asynchronous process whereas the device shutdown is always sudden and unavoidable. Оne day I will find some smart solution how to change the device instanly without stopping the device, so i hope. Thats is known long-standing problem.
Maiko is the true kernel driver. As you may notice the maiko always keeps the device opened. By design. When winamp is stopped the device do anything and consume no resources but the windows kernel is aware that winamp is still there, lurking for hot kernel news. The plugin was designed for almost instant fire-up and seamless playback. It plays different sample rates, channels, bit rates - all of them without gaps like a whole.
So, maiko catch device shutdown callback from kernel (aka ultimate kick off) and without any proper code to react, it crush . Also worth to mention when maiko is just lurking the device, the winamp can be booted off by exlusive mode application.
Sorry, you have to close the winamp before any exclusive mode activity. I'm aware of the problem and looking for inspiration to fix it.

[VipZ]

Thanks Silver for the info. I look forward to your inspiration to fix

I don't really mind the failing playback as its expected, one could just close and reopen. The stalling and requiring task manager to close Winamp is the annoying part and loosing settings/playlist queues etc in the process.

Still the best output plugin for Winamp by far

hi nice plugin works for me since i tried the v0.14.1 after 0.8 not working.
Previously used ASIO4ALL but yours handles silents gaps perfectly!
Could you please patch v.16 to handle visualizations please?

[SilverBird775]

neep8,
Hi need to know your Status log (see Maiko configure) and input plugin that cause the visualization loss.

The build-in visualization could be a bit choppy but it seems i could not do much about this. I'm using Classic Spectrum Analizer as well because the build-in ones are tiny and looking boring.

[SilverBird775]

0.17 - Ideal lip-sync video and better visualizations.

[kerimcem]

thanx for the update

[sullysnet]

I look forward to future updates thanks
I just bought a receiver for my computer setup and I wanted to use something more
than direct sound. I am using SPDIF out of my Creative X-FI but my ASIO output plugin
will not work over SPDIF (for some reason). I am curious about your input plugin and how
it will compare to default or to MAD plugin.

[SilverBird775]

sullysnet

Congrats for a purchase!
X-Fi is the very "special" card. I knew it because X-Fi Elite is my primary card for headphones n gaming. It's chipset itself is very tricky and drivers as well. No i take my words back because drivers are ugly as sin actually. When you want bit copy you better go ASIO. I don't know what is wrong for you but you better try to fix it. If you want *just to play* audio then go with WASAPI and upsampling. The quality loss is minor this way and usability are not comparable to exclusive output. 192/24 for gaming mode and 96-192/24 for audio creation. Avoid the 44100->48000 conversion scenario when possible.

Two years ago my output plugin was so immature and got so much negative response i learned from it. The input plugin would use feedback from output plugin to optimize the decoder. It's very essential idea to extract as much dynamic range from the dead compressed tunes as possible. For now i can only say it's worth it, it is unique and very innovative for a freeware. There is still a lot work to do and lot of problems to work around. The mpeg decoder is incredibly hard task to do and twice as hard to beat the matured decoders. Could not give a time for alpha release, probably the 4th quarter.

IMHO the default mpeg decoder in winamp is superior to the most decoders out there. I know exactly how much painful to make them but sorry most decoders are overrated. My hearing is degrading over time but still hear the MAD flaws. The default decoder may be not all way precise but it is neutral if you know what i mean, it does not surprise you all of sudden.

[kerimcem]

[2011 02 12][v 0.18]
* Bug showdown, a lot was burned and died violently (maintenance release :-D).
Even more tricky buffering logic to support badly designed input plugins.

thanx for the update

[SilverBird775]

kerimcem
Looks like the great pension was promised to you for a daily update check ;-) I promise to inform the users for any essential updates. Just like to keep things clean and clear and so trying to sort out the minor changes.

to all
By the way, i've noticed the p**n filter stripped off the link from the title post. Unfortunately the free hosts are suffering from the fishing pages and illegal content and so the whole domain could be banned unexpectedly. The link is still alive you just cannot see it. Sorry for this, i'm always looking for a serious free bannerless host.

The homepage mirrored here:
http://maiko.elementfx.com/