2010/5/12 pl bossart bossart.nospam@gmail.com
It seems the requirement is just to have as least wakeups as possible in order to maximize power savings. If so, then how about setting the period size slightly smaller than the ring-buffer: the difference being just enough to refill the ring buffer. Of course, you would have to enforce full-buffer-size as the start threshold. We do just that to implement low-power-audio-mode for latest Samsung SoC's I2S blocks.
Thanks for the heads-up Jassi, this is interesting info that does show the need to reduce the number of wakeups in embedded low-power solutions... This might be almost equivalent to the timer approach in terms of # of wakeups, however the timer can be reprogrammed on-the-fly whereas periods can only be changed by closing and reopening the device. You can also adjust the timer shall underflows occur. And the timer slack lets the kernel group events. Not to mention that you will need specific apps written to make use of this mode. The only drawback of the timer approach is that you need to keep track of drifts between system and audio clock and that you need the hardware and driver to report the hw_ptr with precision.
The problem is PA require hw_ptr with precision but PA server did not provide same precision to PA client through alsa-pulseaudio plugin , this inaccuracy lead to underrun easily