Created attachment 3743 [details]
Improve WASAPI audio backend latency

Currently, the WASAPI backend creates a stream in shared mode and set's the device's callback size to be half of the shared stream's total buffer size.

This works, but doesn't coordinate will with the actual hardware. The hardware will raise an interrupt after every period which in turn will signal the object being waited on inside of WaitDevice. From my empirical testing, the callback size was often larger than the period size and not a multiple of it, which resulted in poor latency when trying to time an application based on the audio callback. The reason for this looked something like:

* The device's callback would be called and and the audio buffer was filled.
* WaitDevice would be called.
* The hardware would raise an interrupt after one period.
* WaitDevice would resume, see that a a full callback had not been played and then wait again.
* The hardware would raise an interrupt after another period.
* WaitDevice would resume, see that a full callback + some extra amount had been played and then it would again call our callback and this process would repeat.
 The effect of this is that the pacing between subsequent callbacks is poor - sometimes it's called very quickly, sometimes it's called very late.

By matching the callback's size to the stream's period size, the pacing of calls to the user callback is improved substantially. I didn't write an actual test for this, but my use case for this was my Dreamcast emulator (https://redream.io) which uses the audio callback to help drive the emulation speed. Without this change and with the default shared stream buffer (which has a period of ~10ms) I would get frame times that were between ~3-30 milliseconds; after this change I get frame times of ~11-22 milliseconds.

Note, this patch also has a change that removes passing a duration to the Initialize call. It seems that the default duration used (when 0 is passed) does typically match up with the duration returned by GetDevicePeriod, however the Initialize docs say:

>To set the buffer to the minimum size required by the engine thread, the client should call Initialize with the hnsBufferDuration parameter set to 0. Following the Initialize call, the client can get the size of the resulting buffer by calling IAudioClient::GetBufferSize.

This change isn't strictly required, but I made it to hopefully rule out another source of unexpected latency.