[alsa-devel] [RFC] ALSA: pcm_lib - read/write IO improvement

Jarkko Nikula jhnikula at gmail.com
Wed Apr 14 08:58:02 CEST 2010

On Tue, 13 Apr 2010 19:01:35 +0200
Takashi Iwai <tiwai at suse.de> wrote:

> > So by not doing the padding the distance to xrun is about the same and
> > the wake-up semantics remains the same. I understood from the thread
> > below that not all applications like if the wake-up happens before
> > avail >= avail_min what would happen with the second idea.
> > 
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2009-December/023986.html
> Well, my understanding is that it's an application thing.
> It feeds the unaligned data while it expects the aligned wake-up.
> Or, any other real example that doesn't work?
Actually I noticed this by wondering why there are wake-ups happening
only for every second period even if there are only two periods. E.g.

aplay -D hw:0 -f dat --period-size=1024 --buffer-size=2048 /dev/zero

Then I noticed that this situation occurs if the hw_ptr has advanced
from the period boundary when checking for the avail in
snd_pcm_lib_write1 and snd_pcm_lib_read1 happens.

Let's image with the above command. First the both periods are filled up
and stream started.

Int 1
- appl_ptr = 2048
- hw_ptr >= 1024
- avail >= avail_min
- wake-up

Process running
- Filling up the period 1 
- Let the hw_ptr be 1026 in next iteration of snd_pcm_lib_write1
-> padding two frames into period 2

Int 2
- appl_ptr = 3074
- hw_ptr >= 2048
- wake-only if hw_ptr >= 2050
- Let the hw_ptr be 2049 -> no wake-up

Int 3
- appl_ptr = 3074
- hw_ptr >= 3072
- avail >= 2046
-> wake-up

Process running
- Padding rest of frames into period 2
- Filling up period 1
- Again if the hw_ptr has advanced, then one or more frames are padded
into period 2 and avail can be less than 1024 when the next interrupt

Now since the hw_ptr is always greater or equal in process running time
than wake-up time, it means that padding usually happens and most
usually the avail < avail_min when the next interrupt happens (unless
there is a long int latency at that time).

What I'm typically seeing that the avail_max is very near to buffer
size even under idle system. However, xruns do not occur very often
even if there are some busy loops running so the scheduler seems to do
good work by waking up us early enough :-)


More information about the Alsa-devel mailing list