[META] ensure 0 Pa_OpenStream() suggestedLatency param means "use minimum implementable latency"

[PortAudio-admin]

Issue created by @RossBencina

Some host APIs clamp the lowest latency to the low default latency or some other artificially high or safe value -- this make it impossible for the user to tweak down to the lowest technically achievable latency.

This ticket is about removing all such clamps. It is related to ticket #98 concerning computing buffer sizes from suggestedLatency values.

Close when these are all closed: #98, #205(see Resolution criteria below)

We decided that a 0 suggestedLatency means "use minimum implementable latency (i.e. double-buffer at framesPerBuffer or similar)." Note that this allows setting latency below the recommended low latency reported by the device in get device info

See: http://music.columbia.edu/pipermail/portaudio/2010-July/010681.html

Fixing this means making sure that implementations don't artificially clamp buffer sizes to recommended values, or any other tweaks like that. DS used to do this, now it is fixed. Ross will also review WMME and ASIO to make sure they conform. Someone(s) else will need to review the other implementations.

182 PA/CoreAudio ignores Pa_OpenStream() suggestedLatency param

See also: BufferingLatencyAndTimingImplementationGuidelines

=== QA notes ===

One way to test this would be by reviewing the results form the patest_suggested_vs_streaminfo_latency test. When suggestedLatency is 0, reported stream latency (for output) should be duration(framesPerBuffer) + fixedLatency. The results from the test should be able to be automatically analysed to determine the fixed latency component and check that results for larger latencies are consistent with that.

=== Resolution criteria ===

This ticket will be closed when the following three conditions are met:

1. A code review has made a review of the codepaths involved in interpreting suggestedLatency and has established that there is no artificail clamping. This is part of the review criteria for #98 as well. See code review ticket #205
2. The code review and wiki method descriptions from ticket #98 make it clear that there is no systemic block to lowest latency. The summary of each algorithm should document what technical constraints in the algorithm determine the lowest achievable latency.
3. The results of the patest_suggested_vs_streaminfo_latency graphs are in line with the expected documented constraints from the previous point. Specifically: with an very small client framesPerBuffer (say 16 frames), latency should not usually be constrained at much higher than 16 frames. This check should be part of #205

[PortAudio-admin]

Comment by @RossBencina

I'm working on WMME, DS and ASIO. I'm reviewing the code to see if the clamps are present.

[PortAudio-admin]

Comment by @RossBencina

Dmitry says:

1. Handling of 0 suggestedLatency value. WASAPI - ok, Alsa - ok, will check Jack. http://music.columbia.edu/pipermail/portaudio/2010-September/010906.html

[PortAudio-admin]

Comment by @RossBencina

TRAC migration: propagating ticket status from TRAC

[RossBencina]

Add test: Resulting latency should be monotonic with respect to the suggested latency.