# Finally, WASAPI / DirectSound alternative **URL:** \ **Category:** Windows\ **Created:** [July 21, 2017, 4:56pm UTC](https://forum.juce.com/t/finally-wasapi-directsound-alternative/23401 "2017-07-21T16:56:38Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![irdbisa](https://avatars.discourse-cdn.com/v4/letter/i/eb9ed0/32.png) [@irdbisa](https://forum.juce.com/u/irdbisa)\ **Post date:** [July 21, 2017, 4:56pm UTC](https://forum.juce.com/t/finally-wasapi-directsound-alternative/23401/1 "2017-07-21T16:56:38Z")
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. Alas… 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. > **[AudioGraph Class (Windows.Media.Audio) - UWP app developer](https://docs.microsoft.com/en-us/uwp/api/windows.media.audio.audiograph)** > > Represents an audio graph of connected input, output, and submix nodes that manipulate and route audio. 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. > **[lilpolywog/audiograph](https://github.com/lilpolywog/audiograph)** > > audiograph - Windows AudioGraph native C++ with cppwinrt headers. 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: > **[Microsoft/cppwinrt](https://github.com/Microsoft/cppwinrt)** > > cppwinrt - C++/WinRT is a standard C++ language projection for the Windows Runtime. ---
**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\ **Post date:** [July 21, 2017, 5:04pm UTC](https://forum.juce.com/t/finally-wasapi-directsound-alternative/23401/2 "2017-07-21T17:04:34Z")
but did they add the ability for us to use `juce::MidiInput::createNewDevice(const String &deviceName, MidiInputCallback *callback)` on windows tho?!?!? ---
**Author:** ![irdbisa](https://avatars.discourse-cdn.com/v4/letter/i/eb9ed0/32.png) [@irdbisa](https://forum.juce.com/u/irdbisa)\ **Post date:** [July 21, 2017, 5:28pm UTC](https://forum.juce.com/t/finally-wasapi-directsound-alternative/23401/3 "2017-07-21T17:28:08Z")
I don’t know, I was only working with audio… I see that MS published a new MIDI API that can be accessed from native C++ with cppwinrt. > **[Microsoft/Windows-universal-samples](https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/MIDI)** > > Windows-universal-samples - API samples for the Universal Windows Platform. Although it does not seem to be able to create new virtual midi input / output devices. I have done this on Windows myself, it involved writing a driver with the WDK. Not for the faint of heart. ---
**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\ **Post date:** [July 21, 2017, 7:36pm UTC](https://forum.juce.com/t/finally-wasapi-directsound-alternative/23401/4 "2017-07-21T19:36:14Z")
roger that. I leave that task to whoever wrote LoopMidi as that solution is fantastic. ---
**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\ **Post date:** [July 24, 2017, 8:04am UTC](https://forum.juce.com/t/finally-wasapi-directsound-alternative/23401/5 "2017-07-24T08:04:49Z")
The new MIDI API is already available in JUCE - look under the options of the `juce_audio_devices` module. > [@Experimental support for the Windows Runtime MIDI API](https://forum.juce.com/t/experimental-support-for-the-windows-runtime-midi-api/21049): > > Hi everybody, We’ve just added EXPERIMENTAL support for the Windows Runtime MIDI API to the develop branch, which enables machines with Windows 10 Anniversary Update installed to connect to Bluetooth Low Energy (BLE) MIDI devices. However, there are some very important caveats: Once a BLE MIDI device is paired, the WinRT MIDI API will always list it as available, even if the device is powered off. Sending or receiving sysex messages is very likely to cause a hang. The WinRT MIDI API…