WASAPI buffer management seems flawed

[peeeeter]

Although I'm new to audio I/O programming, after some pretty in depth experiments today I believe Microsoft really wants to manage the buffer fill for you, and therefore the means to control latency is via the hnsBufferDuration in Initialize(), which should be passed from the "latency" stream control during init/setup, as it probably is with other backends, but not WASAPI?

All my experiments are with sio_sine. I tried managing the latency by giving the write callback to use only the amount of data I wanted to give it. For example, 512 frames, but this resulted in AUDCLNT_E_BUFFER_TOO_LARGE (after doing some debugging). The maximum I was given was 192000 (4sec), with a minimum of 512 on pre-roll, and 0 during streaming. I was expecting to maybe to see some occasional underruns, but instead I get this clearly garbage error from Microsoft. I can see on MSDN that there's nothing about HAVING to fill the buffer entirely, but if you don't, it seems you open yourself up to not working, and getting a failure so bad, Microsoft has yet to come up with a proper hresult for it.

After hard coding the param sent to Initialize to .01sec rather than 2 or 4 sec or whatever it was, I can get the sine tone to work just great with buffers of 480, by ensuring I always write the maximum requested frames, which is either 480 or 960.

I'm using an Edirol UA-101, Win 7, latest from git (323fb1a). Obviously I could see how maybe this would be device dependent. Further MSDN browsing shows that there are even more low latency improvements on Win 10... not sure how that affects things moving forward.

[andrewrk]

Thank you for this error report. Do you have a proposed change to fix this?

This is something I would eventually look into but it sounds like you are now quite familiar with the problem and also have test hardware on hand. Willing to take a stab at it?

[peeeeter]

My best guess is that the intended behavior of the client is to always fill the buffer, which would mean that min/max frames would be equal as they are on some other backends, I guess. I'm not super confident of that, but since this seems to be the behavior of all the examples/tests to comply with other backends, it seems like it will ... work. I'm happy to try to help out, but it might be a week or two.

[wegylexy]

@andrewrk Please take some time to review and accept/reject the pull requests. Thank you.