[alsa-devel] ALSA calling pcm_pointer excessively?

[Trent Piepho]

On Thu, May 10, 2012 at 12:06 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> The question is - what would cause ALSA to hammer away at the buffer
> like that - checking it every 16 or 8 DMA bytes transferred?  I'm also
> seeing around 75% system CPU time, which really isn't good.
>
> The above was captured while aplay was running, with no apparant audio
> corruption.

I've had this happen, but not with aplay.  I sent something to the
list a few months ago about it.

The problem is triggered when writing to ALSA with writes that are
unequal to the period size and using sampling rate conversion in an
ALSA plugin.  Code in alsa-lib will get into a loop calling poll() on
the pcm fd, and ALSA's poll() calls the pointer method to figure out
if there is enough buffer space free to return or if it poll() should
block.

That is all fine, but rather than write more data when poll() returns,
alsa-lib decides to call poll() again.  So it's stuck in a tight loop
calling poll() which isn't blocking.  Eventually there will be enough
space in the buffer that alsa will write some data and poll() will
block.

Basically poll() will return when there is at least X bytes available
in the buffer.  X = avail_min.  ALSA will only write more data when
there is at least Y bytes free in the buffer.  The bug is X < Y.  This
only happens when sample rate conversion and only if the app doesn't
call snd_pcm_writei() with full periods.  While the available space in
the buffer is > X and < Y, ALSA is in a tight loop calling poll()
which calls the PCM's pointer method.  If X == Y, then this would
never happen.