2010/5/12 pl bossart <bossart.nospam@xxxxxxxxx> > > 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
