WASAPI woes


#1

I was having issues with WASAPI, and thought maybe it was just the screwy laptop I was using.
Now I’ve tried it on a bunch of different computers, and find that it is pretty universally problematic.

Primarily, when initializing a device, it always reports “the inputs and outputs have no common sample rate”.

This is using JuceDemo, compiling from the tip. I’ve seen this issue for months now.
Any idea when this might get addressed?


#2

Would love to help, but haven’t seen hthat appen on my own machine… There’s a JUCE_WASAPI_LOGGING flag that might show some useful info?


#3

I know from a large customer base that this happens on a lot of computers - around one third of Windows installations.

Jules, its easy to reproduce if you setup your (consumer level) audio card to use different sample rates in Windows’s audio settings / advanced.

The AudioDeviceManager cannot handle this as it require in- and output to run synchronously.


#4

ah… I see… Hmm, bit tricky to fix that. Drat.


#5

Maybe as a workaround that avoids async devices, WASAPI exclusive mode can override those Windows settings? (havent tried)


#6

… and in my book this again is proof enough, along with the subpar general performance of the API, and the past experiences with DX effects and similar attempts by Redmond, that WASAPI is another failed attempt by Redmond to replace working technology with their “not made here” mentality.

IMO, WASAPI is not worth supporting.


#7

If you want JUCE on Windows outside the hardcore pro-audio, there are no alternatives to WASAPI.


#8

That is sadly true. WASAPI is indeed crap though.


#9

The current solution is simple: the user has to reconfig the devices to make it so.

The complicated solution is allowing us JUCE programmers to place a custom resampler/use JUCE’s ResamplingAudioSource by default in the device chain.


#10

Or force users to use ASIO4ALL, and bundle and install that. Hmmmm, pain in the butt though.