On Mon, 2010-06-28 at 11:13 +0800, Raymond Yau wrote:
2010/6/28 David Dillow dave@thedillows.org
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.
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() di 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.
it is unlikely to set avail_min or minimum period size to a value less than the PCI brust size if your driver are using DMA transfer
Raymond, you seem to have missed the part where I said that setting avail_min to 1 is not going to magically change the way hardware works. Of course it will not get you wakeup latencies lower than the size of the DMA transfer; heck, it won't get you wake up latencies lower than a period size, should read/write have to sleep!
However, setting it to 1 was useful in that it said to wake up as soon as possible. Possible in this case means as soon as the next period has elapsed, which may be quite a bit longer than 1 sample. It is quite like the example I gave of poll() -- giving a timeout of 1ms to poll() on a machine with HZ=100 used to mean that you get at least a 10ms timeout. Even with NOHZ, HPET timers. and HZ=1000 today, you have no guarantee that your process is at the head of the run queue. You may not even get scheduled to run for several seconds on a busy system.