QAudioInput on Windows hoards data in pull mode

I have a typical use case for pull mode: at given times, my app needs to poll the audio input, up to the latest data available (for minimal latency). Playing with the attached test code I found that on each system there is an audio "chunk" size: incomplete chunks cannot be read and are not reported as available. The chunk size imposes a minimum latency on audio input, and should therefore be kept as small as possible. Contrast this with the audio input's buffer size, which in pull mode may have to be large to accommodate irregular polling by the user.

This is done correctly on the Mac: the chunk size is always close to the number of bytes arriving (for the selected audio format) in 11.6ms. In Windows XP, however, the chunk size is always set to 20% of the buffer size, and in Vista it's 80% of the buffer size. In push mode that's acceptable: if the user needs the data sooner, she can always reduce the buffer size. This works because the audio backend can write to the user's device immediately.

In pull mode, however, it makes no sense for QAudioInput to hoard data when the user explicitly polls for it. For my application this means that in Windows I need to set the buffer size small in order to keep the latency down - but then I get buffer frequent overruns when the app is swamped (e.g., things happening in the GUI).

Proposed fix: the chunk size in Windows should be determined as it is on the Mac, as the number of bytes arriving in some reasonable time frame (~10ms) in the given audio format, irrespective of the buffer size.