#98
- Created on2011-02-02 01:55
- Reported by
- StatusNew
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
[META] Harmonize Pa_OpenStream() suggestedLatency param to native buffer size calculations
Different host APIs interpret Pa_OpenStream suggestedLatency values differently. To some extent this is OK because it reflects the differences in buffering mechanisms. However, as much as possible we have decided that all host APIs should use similar calculations.
Close when #205 is closed. (see Resolution criteria below)
This is discussed in detail here: BufferingLatencyAndTimingImplementationGuidelines
Earlier discussion between Dmitry and Ross is archived here:
http://music.columbia.edu/pipermail/portaudio/2010-July/010681.html
Ross is reviewing WMME, DS and ASIO with regard to this ticket.
The current ASIO computations may be incorrect (see ticket #93)
> #93 PA/ASIO !SelectHostBufferSize() doesn't take user framesPerBuffer into account
This ticket is also related to the way default latency values are computed (see ticket #97)
This ticket is related to the way suggestedLatency==0 is interpreted (ticket #99)
ALSA, !CoreAudio etc will need to be reviewed once further progress is made on this ticket.
#182 PA/CoreAudio ignores Pa_OpenStream() suggestedLatency param
=== Resolution criteria ===
This ticket will be closed when the following two conditions are met:
- A review of native buffer size computation code has been undertaken, and the method used to compute host buffer sizes is concisely summarised on the wiki page for each host API.
- A visual inspection of the graphs created by patest_suggested_vs_streaminfo_latency appears consistent with our expectations (using WMME and DS as a guide).
Both of these tasks are part of code review ticket #205.
Close when #205 is closed. (see Resolution criteria below)
This is discussed in detail here: BufferingLatencyAndTimingImplementationGuidelines
Earlier discussion between Dmitry and Ross is archived here:
http://music.columbia.edu/pipermail/portaudio/2010-July/010681.html
Ross is reviewing WMME, DS and ASIO with regard to this ticket.
The current ASIO computations may be incorrect (see ticket #93)
> #93 PA/ASIO !SelectHostBufferSize() doesn't take user framesPerBuffer into account
This ticket is also related to the way default latency values are computed (see ticket #97)
This ticket is related to the way suggestedLatency==0 is interpreted (ticket #99)
ALSA, !CoreAudio etc will need to be reviewed once further progress is made on this ticket.
#182 PA/CoreAudio ignores Pa_OpenStream() suggestedLatency param
=== Resolution criteria ===
This ticket will be closed when the following two conditions are met:
- A review of native buffer size computation code has been undertaken, and the method used to compute host buffer sizes is concisely summarised on the wiki page for each host API.
- A visual inspection of the graphs created by patest_suggested_vs_streaminfo_latency appears consistent with our expectations (using WMME and DS as a guide).
Both of these tasks are part of code review ticket #205.
Leave a comment
after a quick re-test with WMME it seems like it's better to use at least 3 buffers if possible (total latency with 2 buffers is higher than with 3 to get stable results).
I'm working on some code that tests different buffer values to see what works best.
here's a page that says KMixer uses 10ms buffers internally:
http://msdn.microsoft.com/en-us/library/ff536484(VS.85).aspx
http://www.microsoft.com/whdc/device/audio/default.mspx
I'm working on some code that tests different buffer values to see what works best.
here's a page that says KMixer uses 10ms buffers internally:
http://msdn.microsoft.com/en-us/library/ff536484(VS.85).aspx
http://www.microsoft.com/whdc/device/audio/default.mspx
r1744 mostly resolves this for DirectSound, however in the case of full-duplex streams with fixed userFramesPerBuffer, the buffer adapter adds extra output latency equal to userFramesPerBuffer -- this extra latency is not taken into account when interpreting suggestedLatency. Therefore full duplex output currently reports userFramesPerBuffer more latency than requested.