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

[Raymond Yau]

2010/5/12 pl bossart <bossart.nospam at 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.
>

it depend on the ratio of watermark and the buffer time

PA use 20 ms watermark and 2 s buffer time which require the driver report
hw_ptr with precision . if the watermark is 50% of the buffer time ,this
will fall back to the traditional model two periods per buffer

so it depend on whether PA allow user to adjust the watermark for their
desktop or laptop