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

[Takashi Iwai]

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

BTW, regarding the PCM core implementation:
one missing thing in the PCM core is a proper way of queuing before
trigger(START) and a proper clean-up after trigger(STOP).  Since the
trigger callback is atomic (in the ALSA sense), it cannot take a long
task.

For a long task like buffer-prefetching or DMA clean up, there might
be a need for yet another callback, such as ops->pre_start() or
ops->post_stop(), and call this before the spinlocked trigger calls.
For example, pre_start should be used to send the available data (up
to appl_ptr) to the hardware.


Just $0.02 as now, though.


Takashi