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