Open PortAudio-admin opened 13 years ago
Comment by @RossBencina
We need status on this issue for all host APIs.
I (rossb) will test WMME, DSound and ASIO. Someone else will need to test the others.
A test that checks that suggested latencies are non-zero would help.
Comment by @RossBencina
Dmitry says:
- Returning sane values in the recommended latency device info fields. WASAPI - ok, Alsa - ok, will check Jack. http://music.columbia.edu/pipermail/portaudio/2010-September/010906.html
Comment by @RossBencina
Phil to review which host APIs have issues
Comment by @RossBencina
TRAC migration: propagating ticket status from TRAC
Comment by @philburk
Raspberry Pi (ALSA) has default latency too low, #246
Issue created by @RossBencina
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
DirectSound - see Ticket #122
WASAPI - Dmitry says OK
ALSA - see Ticket #39, Dmitry says OK, check and maybe close it.
!CoreAudio - see Ticket #175
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:
We can test whether the values are non-zero.
On specific machines and host APIs we can test whether the default values cause glitches
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:
Ideally we would also fulfil this criteria, but we won't: