Raymond, I've asked you before to not trim cc lists. Believe it or not, people may be involved in a conversation even if they are not on the mailing list. In this case, Hans probably doesn't care, but you cannot make that assumption.
On Mon, 2010-06-28 at 08:37 +0800, Raymond Yau wrote:
2010/6/28 David Dillow dave@thedillows.org
Perhaps documentation that recommends setting avail_min to 1 when using read/write to avoid this issue would be helpful, in lieu of changing the ALSA code or giving concrete guarantees.
Dave
Refer to http://article.gmane.org/gmane.linux.alsa.devel/69333/match=avail_min
avail_min cannot be less than period size , however set_avail_min() did not return any error when the value is less than period size and this mislead the programmers to believe that they can set avail_min to 1
They used to be able to, and it would work. You likely cannot get latency that low, but anyone that was expecting for that to magically change the way hardware works is fooling themselves. avail_min is like the timeout argument to poll() -- you're guaranteed at least that value, but you may get something much larger.
I understand the rationale given for patch b0b7d0 to alsa-lib, but limiting avail_min in this way removed a workaround for the muddled snd_pcm_read/write() semantics. I suppose it is still possible, if someone wants to color outside libasound -- the kernel still allows it.
if you want low latency, you need to use small period size
Small period sizes are often needed for low latency -- 10ms is common for VoIP -- but if you are stuck with a device that can only do two periods per buffer, the current read/write code will cause unstable audio with frequent overruns. You can add another round trip to the kernel with snd_pcm_wait(), but that's suboptimal and should not be required.
You can get reasonably good stability on limited devices with avail_min == 1, or with a read/write that doesn't force you to wait two periods when trying to work with one.
Dave