No, WASAPI isn’t a japanese horseradish sauce, it’s Microsoft’s new audio API, available in Vista and Windows 7, and I’ve just added support for it to the build.
I’ve only just checked in a first version of it, and so far I’ve only tried it in a vista virtual machine on my mac, but if anyone wants to try it out, I’d be keen to hear of any problems you hit.
It looks like it’ll be a good API for audio apps, as it performs much better than DSound, without needing exclusive soundcard access like ASIO tends to.
I tested WASAPI on three machines, with different sound hardware. No stability problems and works great
However, i was a bit dissapointed with latency. All machines (with different soundcards/audio interfaces) performed the same. When playing VSTi (midi => audio) it would go very low, but when playing a VST effect (audio => audio) 256 sample buffers would crackle and i had to raise it to 512 for smooth sound. That’s much better than DirectSound but still too much for real time many playing purposes. The result was the same across all hardware systems.
Did anybody have same results and is it an inherit windows problem?
Also, could we get WASAPI exclusive mode exposed thourgh JUCE? (Its supposed to perform better)
Thanks for the answer! I suppose that exclusive mode will be able to go lower.
I found that there is a CPU hog problem as well…
On a simple program juce’s WASAPI takes 30% CPU resources while the same program with juce’s ASIO takes 0% in task manager.
Hello.
If I have two devices with the same name(it is possible in Vista and Windows7) - I can select only first via audio device manager in juce demo.
Thanks, Michail.
This bug possible to reproduce in:
Windows 7 x64 (x32 should too), 2 - Core CPU, juce version tested - 2/12/2010.
I am using jucedemo from prebuild’s tip.
When i start audio demo, wait a while - juce demo CPU usage up to 30-50% (of 2 cores). If I use DirectSound - all works without any problems.
I was trying add Thread::sleep(0) into audioDeviceCallback - not helps.
Have you any idea?
Thanks!
UPD: Forgot to say - more then 70% of use usage in kernel mode.
Still reproduced, but works better (need more time to do some stuff to reproduce).
Sometimes bug appears when I change input device to <>. Sometimes when I change buffer size. Sometimes I just need to wait… And sometimes another instance of JuceDemo helps…
Does Thread::yield() do the trick for you? I’d be a bit reluctant to put in a Sleep(1) because if the latency is very low, that’s a significant amount of time.