[alsa-devel] [RFC] disabling ALSA period interrupts

[Jassi Brar]

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.