Implement fix for glitching WASAPI playback

[sveinse]

Fixing #303 by reducing the sleep delays on playback in polled thread mainloop. This reverts the sleep delays back to the same values as used in the stable versions of PA.

[dmitrykos]

@sveinse, thank you for a fix! Introducing sleep_ms_out /= 2 in a separate line is a good approach and falls into the same manner as it was done in the blocking API.

[kmatheussen]

Is there a CPU penalty only sleeping 2ms (which happens when recording)? If not, wouldn't make sense to sleep only 2ms for playback as well? Unless windows guarantees hard RT sleeping accuracy here, why take the chance sleeping more?

[dmitrykos]

There is always a penalty (more instructions to process) if we call system and our APIs frequently (polling). According to the Microsoft docs/example (https://docs.microsoft.com/en-us/windows/win32/coreaudio/rendering-a-stream) we do not need to poll host buffer to often and polling 1/2 of the buffer duration is sufficient to have no underruns.

Busy polling every 2 ms is too often for playback to my view if there is no obvious reason for it (requested latency > 4 ms), with recording there wasn't a choice to do other way as packets were expiring too early on some machines.

[kmatheussen]

Of course there is a penalty. My question was rather if the penalty is anything to care about. Also, how can you be sure polling 1/2 of the buffer duration is sufficient when portaudio doesn't report glitches in wasapi? I mean, it's easy to overhear a few glitches now and then.

[dmitrykos]

To my view the increased CPU consumption can be a problem as it results in a CPU-hungry apps that are disliked by the end-users. Some systems would even kill such process if it exceeds some certain threshold of CPU consumption for the foreground or background process. Glitches can be solved by the optimized audio rending from the app's side, also you could do audio rendering not inside the PA's thread but in some other thread which would deliver ready buffers/data into the PA's callback thread.

[sveinse]

@kmatheussen, @dmitrykos As this is is the the merge request for #303, let's keep the discussion in that issue, please. Otherwise the discussion will be all over the place. Thanks.