Please describe the problem:
When using some SIP providers and some sound cards, the output sound is very bad (chopped sound). In my particular case, this doesn't happen when I use 500@ekiga.net _OR_ my internal AppleOnboardAudio soundcard. However, it does happen every time I use French Free's SIP service _AND_ an external USB Hercules Muse Pocket LT soundcard.

I traced back the failures to write errors in pwlib's sound_alsa.cxx: Write() is trying to write 480 bytes, but only 320 bytes were allocated previously (2 buffers of 160 bytes).

Looking at the connection logs, I realised this is caused by a RTP payload size difference: when calling 500@ekiga.net I get:
> First receive data: ver=2 pt=PCMA psz=160 m=0 x=0 seq=45877 ts=160 src=1793690214 ccnt=0
but when using Free's SIP service I get:
> First receive data: ver=2 pt=PCMA psz=240 m=0 x=0 seq=121 ts=2457396442 src=40891477 ccnt=0

Notice the psz difference.

In order to correct this issue, Ekiga would need to wait the first packet coming from the net, and only then initialise the soundcard. From what I've seen in the code, it doesn't work this way: Opal is the one setting the buffers, and this seem to be hardcoded to 320, which seem to cause the problem. I'm not familiar with this source code so I may as well be wrong.

A workaround, which does work for me, is to hardcode "storedPeriods = 3;" in 
PSoundChannelALSA::SetBuffers() method.

In case you wonder why it does work on some soundcards, well, it seems that on most of them (but _not_ usb audio), the driver is hardcoded to accept a minimum number of 3 buffers, so snd_pcm_hw_params_set_periods_near() will round up the value ekiga passes, 2, up to 3. Look for example at the linux kernel's sound/aoa/soundbus/i2sbus/i2sbus-pcm.c: hw->periods_min = 3;

I hope all this makes sense :)

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information: