[alsa-devel] appl_ptr and DMA overrun at end of stream
tiwai at suse.de
Mon May 11 16:21:04 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. 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
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.
More information about the Alsa-devel