The recommended latencies reported in the !PaDeviceInfo structure for some host APIs are 0 or unimplemented.

!PaDeviceInfo docs:
http://www.portaudio.com/docs/v19-doxydocs/structPaDeviceInfo.html

A minimal fix would be to hard code known safe values (although safe values tend to change for different OS versions) A better approach would be to research safe values using a test app that tests different buffer sizes (say using a guided binary search).

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

Related tickets:

WMME - see Ticket #80
> #80 PA/WMME PA recommended deviceInfo->default*Latency values need review

DirectSound - see Ticket #122
> #122 PA/!DirectSound recommended deviceInfo->default*Latency values are (higher than necessary)

WASAPI - Dmitry says OK

ALSA - see Ticket #39, Dmitry says OK, check and maybe close it.
> #39 PA/ALSA PA recommended deviceInfo->defaultOutputLatency will lead to bad pops

!CoreAudio - see Ticket #175
> #175 PA/CoreAudio recommended deviceInfo->default*Latency is 0

What about other host APIs?

Note that the default latency values may interact with the way internal native buffer sizes are chosen. So this ticket is related to ticket #98 concerning harmonising native buffer calculations.

See also: BufferingLatencyAndTimingImplementationGuidelines

=== QA notes ===

examples/pa_devs.c can be used to list the default*Latency values. As a first step we should run this on all platforms and collate the results. This will allow us to confirm that all host APIs are reporting sane values.

The loopback test should have a mode where it tests each default latency value and ensures that audio operates with no glitches (possibly with a range of buffer sizes and sample rates).

Providing "better" default values on some platforms is dependent on conducting a broad survey of workable latency values. Possibly using a loopback automated test instead of the manual test procedure used for WMME in ticket #185, DirectSound #186. See #204

Testing considerations:
- defaults could be too high
- defaults could be too low (glitches)
- defaults could be different with different hardware / os version / user-configured topology
- testing could be done at at different CPU loads

We can test whether the values are non-zero.
- we can audit the code to see how the values are derived. if they're hardwired they're always going to be non-zero
- we can always test on specific machines

On specific machines and host APIs we can test whether the default values cause glitches
- output can be tested manually by user audition
- input can be reliably tested with loopback test

We can manually inspect the default latencies for value (perhaps by graphing them) and from this make an assessment about whether the values are valid.


=== Resolution criteria ===

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

1. All host APIs return non-zero values for deviceInfo->default*Latency (Covered by tickets #201, #202)
2. Default latency values produce non-glitching audio with each host API on some set of machines. At a minimum on our developer machines, ideally on a more broadly tested set of machines. Minimum coverage would be all host APIs and all target OSes. For output this requires listening, for input it requires loopback. (Covered by ticket #203)
3. A code review of each host API indicates that the default latency values are computed sanely. Make sure there are no fixmes, comments or other source-level indications that things are incomplete. Ensure that default latency computations take into account our algorithm (which needs to be concisely specified for the code review). The method employed to determine default latencies for each host API should be documented on the wiki page as part of the code review. (Covered by ticket #205)

Ideally we would also fulfil this criteria, but we won't:

- Default latencies are in line with a large scale survey of workable latencies on each platform where the latency is not system supplied. There is now a ticket for this task #204. It isn't scheduled.