When some of the audio devices don't offer ASIO (these are generally playback only DACs or AV devices) you aren't sure what you are getting without jumping thru hoops.
When using WASAPI Exclusive mode, you are sure of what you are getting, same as ASIO. You were just victim of an unfortunate bug in Multitone itself.
If it's for some reason reversed
@bennetng just provided
proof that the condition is indeed reversed in your code. That certainly explains a lot!
Just testing it now, it appears WASAPI only gives 16 bit access in exclusive mode. This is why Multitone says it can't find a supported format -- it's looking for more bits that are reported as supported by the audio driver.
If an audio format can be set in the Windows audio device settings, it should also work in WASAPI Exclusive mode.
WASAPI Exclusive can definitely do 24-bit. There is plenty of evidence with lots of applications that work just fine in 24-bit with WASAPI Exclusive (e.g. foobar).
However, last time I programmed against WASAPI directly (it was a long time ago), I noticed most devices actually require 24-bit
padded to 32 bit (or the opposite, I don't remember) in the WAVEFORMATEXTENSIBLE spec, otherwise they refuse the format. I don't know if that's still true today.
More generally, WASAPI Exclusive is, in my experience, trickier to make work reliably compared to WASAPI Shared, because some devices can be quite finicky about things like formats and buffer sizes. These problems don't arise with WASAPI Shared because Windows accepts anything and then automatically applies any format conversions and buffer adaptation necessary.
@pkane Have you considered using
NAudio instead of using WASAPI directly? My understanding is that it would abstract away all these problems so that you don't have to get your hands dirty. (I never tried it though.)
@pkane: whatever you do, please make sure WASAPI Shared is not the default. WASAPI Shared is a really bad idea for measurements because of automatic conversions and APOs (including CAudioLimiter) will screw things up big time for unsuspecting users. If you can't make WASAPI Exclusive work, might as well tell people to use ASIO. After all, they can always use
ASIO4ALL or
FlexASIO (which, by the way, does support WASAPI Exclusive in 24-bit!).
Well Kernel streaming in Reaper works with good results. Any chance of that as a choice in Multitone? I have no idea if that is some big hairy problem to include.
Kernel Streaming is really hard to use directly. You'd want to use a library, but few of them support Kernel Streaming for the same reason. A notable exception is
PortAudio.
Technically you can use Multitone with Kernel Streaming today: just use it with
FlexASIO and the
Kernel Streaming backend
I suppose though probably using it like it is in 24 bit, just don't go above -.2 dbFS is more useful than 16 bit would be. One could use the CAaudiolimiter removal trick if that last .2 db is important. I'd maybe be just as happy with a note not to use WASAPI above .2 dbFS actually.
I would strongly advise against using WASAPI Shared with measurements. Unless you are careful you can easily end up with random conversions and APOs that will screw up your results. Use WASAPI Exclusive or ASIO.