On Mon, 2010-06-28 at 11:13 +0800, Raymond Yau wrote: > 2010/6/28 David Dillow <dave@xxxxxxxxxxxxxx> > On Mon, 2010-06-28 at 08:37 +0800, Raymond Yau wrote: > > 2010/6/28 David Dillow <dave@xxxxxxxxxxxxxx> > > > 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
