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

Takashi Iwai tiwai at suse.de
Fri May 14 01:12:51 PDT 2010

At Fri, 30 Apr 2010 08:44:24 -0500,
pl bossart wrote:
> >> I am aware that some changes would be needed in pcm_lib.c, where all
> >> the error checks are done.
> >
> > Plus all the API changes in the ALSA kernel framework, the ALSA kernel/
> > userspace interface, and the alsa-lib interface.
> I am not following this point. If you add a simple flag to an existing
> interface, why would we need to change the kernel/userspace inferface?
> This change should be possible in a backwards compatible manner as an
> additional option provided to the application developer.

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

Thus, before disabling the interrupts completely, we need to revisit
the PCM position handling all over places.  But in general, I think
it's fine to implement such a mode -- it's more intuitive than the
current free-wheel mode we have now.

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?



More information about the pulseaudio-discuss mailing list