Fix test criteria to fix paqa_latency.c

[philburk]

It was failing because the latency was too low.

Now we allow lower latency.

Fixes #742

[philburk]

After discussion with Ross, the plan is to:

1. Start checking at 0.0
2. expect the finalLatency to be >= suggested, UNTIL it clamps and then it should not increase.

[philburk]

expect the finalLatency to be >= suggested, UNTIL it clamps and then it should not increase.

I added that test. But we are seeing failures where the latency hits the maximum and then keeps going up!

Using device #4: 'Maono PD200W Mic USB' (Core Audio)
------------------------ paqaCheckMultipleSuggested - INPUT
 lowLatency  = 0.00441667
 highLatency = 0.01375
 numChannels = 1
 sampleRate  = 48000
   suggestedLatency[ 0] = 0.000000, finalLatency = 0.003396
   suggestedLatency[ 1] = 0.001375, finalLatency = 0.003396
   suggestedLatency[ 2] = 0.002750, finalLatency = 0.003396
   suggestedLatency[ 3] = 0.004125, finalLatency = 0.004125
   suggestedLatency[ 4] = 0.005500, finalLatency = 0.005500
   suggestedLatency[ 5] = 0.006875, finalLatency = 0.006875
     maximumLatency = 0.006875
   suggestedLatency[ 6] = 0.008250, finalLatency = 0.008250
/Users/phil/Work/portaudio/pagit/qa/paqa_latency.c:310 - ERROR - Latency should be == maximumLatency
INPUT CHECK FAILED !!! #4: 'Maono PD200W Mic USB'

also

Using device #7: 'ZoomAudioDevice' (Core Audio)
------------------------ paqaCheckMultipleSuggested - OUTPUT
 lowLatency  = 0.0333333
 highLatency = 0.0426667
 numChannels = 2
 sampleRate  = 48000
   suggestedLatency[ 0] = 0.000000, finalLatency = 0.032313
   suggestedLatency[ 1] = 0.004267, finalLatency = 0.032313
   suggestedLatency[ 2] = 0.008533, finalLatency = 0.032313
   suggestedLatency[ 3] = 0.012800, finalLatency = 0.032313
   suggestedLatency[ 4] = 0.017067, finalLatency = 0.032313
   suggestedLatency[ 5] = 0.021333, finalLatency = 0.032313
   suggestedLatency[ 6] = 0.025600, finalLatency = 0.032313
   suggestedLatency[ 7] = 0.029867, finalLatency = 0.032313
   suggestedLatency[ 8] = 0.034133, finalLatency = 0.034125
     maximumLatency = 0.034125
   suggestedLatency[ 9] = 0.038400, finalLatency = 0.038396
/Users/phil/Work/portaudio/pagit/qa/paqa_latency.c:310 - ERROR - Latency should be == maximumLatency
OUTPUT CHECK FAILED !!! #7: 'ZoomAudioDevice'

[RossBencina]

NEXT STEP: confirm that rounding error is the problem. investigate source of rounding error. consider revising the spec

I think that the test is valid with respect to the current spec.

I think the failing tests reflect a bug in the code in the sense that the test results indicate a violation of the current spec for suggestedLatency in portaudio.h here:

portaudio/include/portaudio.h

Lines 570 to 580 in 5d01510

	/** The desired latency in seconds. Where practical, implementations should
	configure their latency based on these parameters. Implementations should
	round the actual latency up to the next viable value, except when suggested
	latency exceeds the upper limit for the device.
	Actual latency values for an open stream may be retrieved using the
	inputLatency and outputLatency fields of the PaStreamInfo structure
	returned by Pa_GetStreamInfo().
	@see default*Latency in PaDeviceInfo, *Latency in PaStreamInfo
	*/
	PaTime suggestedLatency;

The USB mic result is difficult to interpret because the displayed floating point precision doesn't show that actual latency < suggested latency, even though it must be by the logic of the test.

I suspect the issue is that there is rounding down when the spec says to always round up. This could easily be a bug in PA/CoreAudio. It would be good to know whether the test also fails with other host APIs.

We are undecided whether rounding down within some epsilon should be in specification . It would be user friendly to allow for +/- half (or 1/4 or 0.1) sample period of slop to allow for incorrect rounding in floating point calculations.

I definitely think that the actual latency should be reported as accurately as possible, so the code should not "pretend" to have honoured the suggested latency when it actually rounded down, even a little bit.

[RossBencina]

Suggestions for improving the test:

• Rename maximumLatency -> detectedMaximumLatency and reflect this in the test output/printfs

• Add a third column "final - suggested" where we expect that column to be >= 0. A negative value indicates that the value was rounded down and will indicate by how much.

• Could print the sample period as a reference value. eg display "sample period: 0.000020" under "sampleRate = 44100" where sample period is 1.0/sampleRate

[philburk]

Print the delta value between final and suggested latency with scientific notation.

[RossBencina]

Phil and I agreed to merge this as a failing test once the following two improvements are made:

• Print in seconds (next to sample rate) 1/sampleRate
• Print suggested, final delta