WDM/KS OpenStream does not take framesPerUserBuffer into account when computing native buffering

[RossBencina]

Search for framesPerUserBuffer in src/hostapi/wdmks/pa_win_wdmks.c and witness how it is used. In particular it is not used in calculations of stream->render.framesPerBuffer or stream->capture.framesPerBuffer.

In general I would expect native buffering to be configured to be a multiple of the user frames per buffer, where a minimum of 2 indicates double-buffering. The details will always be specific to the particular native API behavior, but the current code doesn't look correct.

One thing to keep in mind is that the user PA callback should always be able to run for near 100% of the duration of the callback buffer, without inducing glitches. Further details are here:

https://github.com/PortAudio/portaudio/wiki/BufferingLatencyAndTimingImplementationGuidelines

See other host APIs for details.

[dechamps]

In practice, it looks like WDM-KS only takes suggestedLatency into account to calculate the host buffer size:

portaudio/src/hostapi/wdmks/pa_win_wdmks.c

Line 4718 in 18a606e

stream->capture.framesPerBuffer = (unsigned long)((inputParameters->suggestedLatency*sampleRate)+0.0001);

portaudio/src/hostapi/wdmks/pa_win_wdmks.c

Line 4754 in 18a606e

stream->render.framesPerBuffer = (unsigned long)((outputParameters->suggestedLatency*sampleRate)+0.0001);

This is confirmed when looking at the debug output for e.g. a WaveRT device, where the reported Out buffer len is always twice the suggestedLatency, regardless of the user framesPerBuffer.

I agree that this looks wrong - if the user specifies framesPerBuffer, then the host frames per buffer should be a multiple of that.

[RossBencina]

the host frames per buffer should be a multiple of that.

Yes, unless there is a reason that it can not be a multiple (i.e. some low-level driver constraint on hardware buffers). Not sure whether that is applicable in the WDM/KS case.