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

[Clemens Ladisch]

pl bossart wrote:
> Takashi Iwai wrote:
> > 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.

Pointer updates (snd_pcm_avail or implicitly when writing samples) are
still necessary, and the interval between them can never be more than
the buffer time if you want to avoid xruns.

It seems to work fine with a simple test program.

> 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.

When an interrupt happens, we know that the current position must be at
least at the end of the period that was started at the last interrupt.
This code does the following: If it looks as if the current position is
less than that, we know that the period interrupt was delayed and that
an entire buffer was played before the position wrapped around to the
current position, so we have to add one buffer size to get the correct
position.

In practice, this implies an underrun.  Without interrupts, this
underrun could not be detected (except by the fact your own timer
has arrived too late).

> 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).

The boundary is a multiple of the buffer size, so you can use
ptr%buffer_size to get the position in the actual hardware buffer.
The boundary is larger than the buffer size to allow computations on
pointer values even when long xruns happen.

> Here is my latest set of patches before I forget about them.

Instead of a new field in snd_pcm_hardware, you should better use a new
flag so that userspace also knows about this capability.

Following are my own patches that I wrote before I saw yours; they look
essentially the same.

> Still some work to be done on the alsa-lib one, for some reason the
> hw_param->flags field I used gets overwritten if I don't use the
> hw_device. I suspect this is due to some black magic with the
> pcm->hw_flags when slave devices are used.

Until now this field has been used only for flags used internally in
alsa-lib, so this might be a bug in alsa-lib.


Regards,
Clemens