Testing WASAPI event-driven buffering.

[chirs241097]

I have been playing around with event-driven buffering in the WASAPI driver. I've pushed the code (which is currently a WIP) to this branch.

Theoretically this should allow even smaller buffers (therefore even lower latency) to be usable without dropouts. Unfortunately the outcome is not as expected. My testing results are all over the place:

• Conexant CX20753 would happily go all the way down to the driver limit (3.33 ms) and work absolutely fine without any dropouts.
• Terratec Aureon 7.1 USB stutters horribly at 3.33 ms or 5 ms. But it is usable at 6.67 ms.
• Scarlett Solo (2nd Gen) is the worst, to my surprise. It still glitches a lot at 10 ms. Even at 20 ms it's not completely glitch-free. This is a significant downgrade from the original clock-based implementation.

I have done some surface-level profiling, and decided that the Terratec card was simply hitting its limitations. But the Focusrite one is definitely not right. It can reach 1.33 ms in Cakewalk using WASAPI without any issues. It seems the WaitForMultipleObjects call at line 654 always return too late -- it doesn't return until the buffer is almost or already depleted. (The wait time is almost never below 10 ms. Sometimes it even goes up to two times the desired latency.)

Is there any obvious mistakes I have made in the code? I suspect that it might have something to do with Focusrite's driver. Maybe I'd have to get in touch with someone from Focusrite to find out.

Also feel free to test the code on your hardware. Please note:

• audio.wasapi.exclusive-mode must be set to 1 or true for the new code to be effective.
• audio.periods is not used in exclusive mode by this implementation anymore.
• If driver initialization fails with error code 0x88890019 (AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED), try some other values for audio.period-size (a power of two usually works).

Depending on the results, I might make event-driven buffering as an option, or discard it altogether.

[derselbst]

I finally had a chance to test this and gave it a try on my windows laptop. Tested with reverb + chorus at a sample rate of 48kHz.

Tested with the following devices:

• Headset Earphone (Plantronics Blackwire 725)
• Speakers/Headphones (Realtek(R) Audio)

Initially tested with a period-size of 64, both devices complained:

fluidsynth: error: wasapi: failed to initialize audio client. 0x88890020
fluidsynth: error: wasapi: the device period size is invalid.
fluidsynth: error: wasapi: minimum period is 144, default period is 480. selected 128.
Failed to create the audio driver

For the "Headset Earphone (Plantronics Blackwire 725)" device, 144 is indeed the minimum usable period-size.

For the Realtek card, 160 is the minimum usable period-size. Anything between 144 and 160, it complained:

fluidsynth: error: wasapi: failed to initialize audio client. 0x88890019
Failed to create the audio driver

To my surprise, both period-sizes work fine without any dropouts (except for a short, random start-up "hiccup"). This is very good!

---

Performing the same test with fluidsynth's current wasapi implementation yields the following results:

"Headset Earphone (Plantronics Blackwire 725)" with a period-size of 144 has severe dropouts. Using a period-size somewhere around 512 and everything sounds fine again.

"Realtek" card now allows to use 144, but it has various shorter dropouts. Going the way up to 1024 makes all dropouts reliably go away.

So your approach looks really promising!