There many reasons why I do not like WASAPI. The JUCE implementation hides a lot of complexity and actually works quite well in ideal cases. Although If everyone could just use a nice ASIO driver my life would be significantly easier.
So I dove head first into the new Windows AudioGraph API. It is meant to be a replacement for WASAPI for Windows 10 build 14393 and beyond. So far, I like it. There is a lot less code.
It claims to solve a variety of nasty WASAPI issues, but these really get my goat
Issue 1 : When the input / output devices have different sample rates, you are screwed.
issue 2 : Dynamically changing audio outputs when a user plugs / unplugs headphone on a Surface). You are screwed.
Issue 3 : Timing the input samples being captured by a mic with the output buffer callback. This is better but not perfect.
So I spent yesterday creating a Windows AudioGraph example that processes mic input and runs it back out to the default output.
This is the first time is years that I’ve not hated a Microsoft API.
It should be noted that I did COM and MFC programming, which are terrible unholy things.
I may incorporate Windows AudioGraph in a juce powered DAW that I develop.
I wanted to share this stuff, I wish I had this code when I started.
Should Windows AudioGraph be an option in JUCE? So far, I believe so…
Here is what I’ve done so far, you need Windows 10, build 14939. I compiled it in Visual Studio 2015 (service pack 3 required).
You also need cppwinrt headers, read my comments in main.cpp
Here is my working test program.
To access AudioGraph you must have access to the modern Windows API.
Fortunately cppwinrt headers provide native C++ access all the new Windows stuff.
Warning, you must must must read the documentation. cppwinrt is a giant templated com wrapper for the latest C++. It uses all the new stuff (lambas) and the compiler errors will be cryptic to the uninitiated.
You need this to compile: