Paul Davis wrote:
I suppose it depends on what latency we are measuring.I am currently taking the following approach: -for lower latency, you'd do:
Always prepare 2 audio hardware periods of sample frames in advance inside the user app.
1) snd_pcm_wait()
2) write()
3) prepare new sample frames, then go back to (1).
1) snd_pcm_wait()
2) prepare new sample frames
3) write(), then go back to (1).
but for the kinds of things you are describing, your original order
seems OK.
--p
My first concern is avoiding xruns, and preparing new sample frames takes quite a lot of time.
For my application, it does not really matter how long it takes for the samples to reach the speakers, it is just that we have to know very accurately how long it is in fact taking. (so we use the delay() function.)
The other issue is the avoiding of xruns, so I think my suggestion is better than yours for xrun avoidance.
Cheers
James
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
