On Wed, May 12, 2010 at 10:50 PM, pl bossart <bossart.nospam at gmail.com> wrote: >> 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. .... another negative is having to hack the alsa stack. I couldn't use the timer thing because the system has to be woken up from suspend(and I2S intr is one of the wakeup sources) and maybe for moorstown/atom also you'd go to sleep/suspend? make sure if the timer based approach could work there. Also, at least for embedded systems, such audio mode switching is done at a level coarse enough(the user sets the 'Hold' switch) that overall power savings(unloading unnecessary driver modules upon first LPAM suspend and reloading only after the last) is much more than a minor click in playback due to close->open of the audio stream.
