>My second idea was to have a rather big hw buffer (500ms), and then set >the start_threshold to a low value (32 frames for instance). But whatever >my parameters were, I always got a playout delay of about the hw buffer >size.
the output latency is always roughly the size of the hardware buffer. there is no way to avoid this. the best you could ever do would be one period, where there are two periods per buffer (i.e half the buffer size). when i say "the best you could do", the truth is that you probably can't do it. the very first sample you deliver to the hardware will have a delay of 1 period, each subsequent sample has a steadily increasing delay all the way up to the last sample, which is delayed by the length of the entire hardware buffer (2 periods). this assumes that delivery is basically instaneous: obviously, if you take time to deliver it, the delay drops, but the total delay (from when you could have written to when the sound is audible) is the same. i don't know what you're doing, but you might to investigate JACK, which does precisely what you're hoping for, supports the lowest latencies of any supported hardware (with an appropriate kernel), but also bundles it all up in an easy to use API. jackit.sf.net. if nothing else, you can study JACK's ALSA code to see how it does it. its not simple. --p ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
