[alsa-devel] appl_ptr and DMA overrun at end of stream
Jaroslav Kysela
perex at perex.cz
Mon May 11 15:45:49 CEST 2009
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.
All other cases are bad (underruns / overruns) and I'm not sure if we can
do much. There is silence mode in the midlevel of kernel API to fill some
samples in the ring buffer ahead with silence so applications can choose
if last samples will be played in the underrun case or if silence will be
played.
Jaroslav
-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel
mailing list