Please describe the problem:
I while back I sent a private email to Damien and the other Ekiga folks regarding some issues in the ALSA backend for Ekiga/libpt. To make sure that things don't lost or are forgotten here are a few excerpts:

<snip>
That said it would be a good idea if Ekiga would stop enumerating raw
kernel sound cards and instead use the name hinting API. Also you
should play event sounds with libcanberra instead of rolling your
own. libcanberra is a blessed gnome dependency and is both simpler and
more powerful for doing event sounds.
</snip>

And more importantly:

<snip>
Yes. You shouldn't misuse the fragments logic of sound devices. It's
like this:

   The latency is defined by the buffer size.
   The wakeup interval is defined by the fragment size.

The buffer fill level will oscillate between 'full buffer' and 'full
buffer minus 1x fragment size minus OS scheduling latency'. Setting
smaller fragment sizes will increase the CPU load and decrease battery
time since you force the CPU to wake up more often. OTOH it increases
drop out safety, since you fill up playback buffer earlier. Choosing
the fragment size is hence something which you should do balancing out
your needs between power consumption and drop-out safety. With modern
processors and a good OS scheduler like the Linux one setting the
fragment size to anything other than half the buffer size does not
make much sense.

Your ALSA output is configured to set the the fragment size to the
size of your codec audio frames. And that's a bad idea. Because the
codec frame size has not been chosen based on power consumption or
drop-out safety reasoning. It has been chosen by the codec designers
based on different reasoning, such as latency.

You probably configured your backend this ways because the ALSA
library docs say that it is recommended to write to the sound card in
multiples of the fragment size. However deducing from this that you
hence should configure the fragment size to the codec frame size is
wrong!

The best way to implement playback these days for ALSA is to write as
much as snd_pcm_avail() tells you to each time you wake up due to
POLLOUT on the sound card. If that is not a multiple of your codec
frame size then you need to buffer the the remainder of the decoded
data yourself in system memory.

The ALSA fragment size you should noirmally set as large as possible
but that you have at least two fragments in your buffer size.

I hope this explains a bit how frag_size/buffer_size should be
chosen. If you have questions, just ask.

(Oh, ALSA uses the term 'period' for what I call 'fragment'
above. It's synonymous)
</snip>

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information: