Wasapi


#1

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.


#2

I tested WASAPI on three machines, with different sound hardware. No stability problems and works great :smiley:

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)


#3

My understanding is that WASAPI runs at a fixed 10 ms buffer size if you are not in exclusive mode. That sounds consistent with your results.

Matt


#4

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.


#5

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.


#6

Oh, how annoying… Ok, thanks, I’ll make it deal with that…


#7

Thanks fro fix, I’ll check it.
Michail.


#8

Hello.

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.


#9

I rarely update the prebuilt exes - you should build it yourself from the tip code for a better idea of what state it’s currently in.


#10

Hello.
I have tested with latest tip.

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…

Thanks, Michail.


#11

Can’t reproduce on my machine - it just sits at 0%…


#12

OK, I’ll try to do some profiling, maybe it will help figure it out.


#13

Hello.
Changing

if (samplesToDo <= 0)
            {
                if (thread.threadShouldExit())
                    break;

                Thread::sleep (0);
                continue;
            }

to

if (samplesToDo <= 0)
            {
                if (thread.threadShouldExit())
                    break;

                Thread::sleep (1);
                continue;
            }

solves the problem.
Thanks, Michail.


#14

Hmm. Interesting.

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.