[alsa-devel] appl_ptr and DMA overrun at end of stream

Takashi Iwai tiwai at suse.de
Mon May 11 16:14:30 CEST 2009

At Mon, 11 May 2009 15:45:49 +0200 (CEST),
Jaroslav Kysela wrote:
> On Mon, 11 May 2009, Jon Smirl wrote:
> >> Right.  This is the value to check in your case.
> >
> > What do think about redesigning the ALSA DMA interface to support
> > detection of over and under run? Leaving the DMA engine in a loop and
> > not coordinating with ALSA as to where the valid data is does not seem
> > to be a safe way of exchanging data. That interface may be a source of
> > the problems pulseaudio is encountering.
> >
> > A simple solution would be for snd_pcm_period_elapsed() to return
> > physical address of the last valid sample. That would let me avoid
> > playing with  s->runtime->control->appl_ptr. You could provide the
> > same data in the pointer() function.
> More simpler solution is to check the stream state in the low level 
> driver. If it's in DRAINING state, then end of stream is signaled from the 
> application and driver might not queue next buffer.

Ah, yes, that's a more elegant solution.

> We may also add 
> another callback (or use ioctl callback) to pass this stream state change 
> to the lowlevel driver immediately, so the driver might react more quickly 
> on this situation.

I don't think such an extension is needed so far.



More information about the Alsa-devel mailing list