WDM-KS: don't request a zero buffer size

[dechamps]

This fixes an issue where Pa_OpenStream() would fail on WDM-KS WaveRT devices if suggestedLatency is zero.

Fixes #761

[RossBencina]

If this is a workaround for KSRTAUDIO_BUFFER_PROPERTY/RequestedBufferSize not accepting zero, then I think that the the clamp to 1 should be performed just prior to the KSRTAUDIO_BUFFER_PROPERTY command rather than the current patch which reads to me like some kind of long-range action at a distance. Just a suggestion/opinion though. I'm open to any alternate reasoning that would reject my perspective.

I've made other comments at #761, we should try to keep the bulk of the discussion there.

[dechamps]

@RossBencina

I think that the the clamp to 1 should be performed just prior to the KSRTAUDIO_BUFFER_PROPERTY command rather than the current patch which reads to me like some kind of long-range action at a distance

My reasoning for doing it that way is that (1) in general it feels safer to have framesPerBuffer set to at least 1, regardless of which particular WDM-KS API is used; and (2) it makes the PA_DEBUG statement on the next line less confusing - if the clamping is done later then the debug log becomes misleading.

[philburk]

Looks fine except for long lines.

[RossBencina]

@dechamps I'm not completely persuaded by your reasoning because I think my solution guarantees that 0 will not ever be passed to KSRTAUDIO_BUFFER_PROPERTY/RequestedBufferSize whereas your solution relies on maintaining an undocumented invariant "at a distance".

Could we at least add a comment in the code directly prior to where KSRTAUDIO_BUFFER_PROPERTY/RequestedBufferSize is set noting that passing 0 will fail with WinRT devices (do you mean WAVERT? not WinRT?) and linking to #761

Other possible solutions would be:

• add an assert !=0 at RequestedBufferSize site (don't do this!)
• put the clamp at both places.

In the end I'm not going to die on this hill but I'm not entirely comfortable with the patch as it stands.

[dechamps]

@RossBencina

Could we at least add a comment in the code directly prior to where KSRTAUDIO_BUFFER_PROPERTY/RequestedBufferSize is set noting that passing 0 will fail with WinRT devices (do you mean WAVERT? not WinRT?) and linking to #761

Done.

do you mean WAVERT? not WinRT?

Oh wow, good catch. I don't know why I wrote WinRT literally everywhere including in my original bug report, what a brain glitch… fixed in all places.

[dechamps]

The two failing checks are not caused by this PR. Filed #767 to fix the checks.

[RossBencina]

Thankyou!

[dechamps]

I guess this can be merged now?