WASAPI buffer management seems flawed

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.