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

[pl bossart]

> The biggest problem I can foresee is the handling of PCM position.
> In the current implementation, the PCM position continues to go over
> the buffer size until the certain boundary that is close to long int
> max.  Without interrupts (i.e. snd_pcm_period_elapsed()), this
> position update won't work reliably.  If we reduce boundary size as
> buffer size, certainly some code in alsa-lib (or kernel PCM) would be
> confused.

Good catch. I thought the processing was the same whether you called
snd_pcm_period_elapsed or snd_pcm_avail when the timer fires, since in
both cases you call the .pointer routine, but there's some code in
snd_pcm_update_hw_ptr0 that is only executed in an interrupt context.
Likewise there are a bunch of fixes for hw_ptr position that make use
of this boundary field (which I have to admit I don't understand too
much).

> BTW, I'm still wondering whether disabling the IRQ would really give
> so much gain compared with periods=1 or 2 case.  I thought all this
> was about the power-saving, no?  Did someone measure a significant
> difference between periods=0 and periods=2 in this regard?

I don't have data I can post on this mailing list without running into
trouble with legal. For low-power playback where we chase milliwatts,
waking up for no good reason isn't very compatible with the S0i2 modes
defined from Moorestown onwards. In S0i2 the platform is mostly off
which the exception of the audio rendering cluster that is
clocked/powered independently. The entry/exit latency is higher than
for regular C states and the transition costs make you want avoid
isolated interrupts. There's a slew of patches coming from Intel to
introduce timer slacks everywhere, my proposal follows the same idea
of avoiding wakeups and grouping events.
We also have a different use case where we want the ring buffer to be
refilled when a modem provides data. The modem events and ALSA periods
may not be aligned, the delta between events isn't predictable, and
that leads to doubling the number of wake-ups since we need to handle
modem events and ALSA events. Again this interferes with cpuidle
heuristics and prevents the entry in sleep states.