Re: [Ekiga-list] PTLIB alsa plugin status

Damien Sandras wrote:
Le dimanche 01 mars 2009 à 17:53 +0100, Alec Leamas a écrit :
Derek Smithies wrote:
On Sat, 28 Feb 2009, Alec Leamas wrote:

Derek Smithies wrote:

On Fri, 27 Feb 2009, Alec Leamas wrote:
I need a whisky.
Coffee is much better. Don't add any impurities though (milk, sugar etc)
I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-)

After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output:

13:45:49.348      ALSA    Setting buffers, size: 3840, count: 5
13:45:49.402      ALSA    Device default Opened
13:45:49.438      ALSA    Setting buffers, size: 320, count: 5
It is set in opal in

 where soundChannelBuffers is set to the supplied parameter value.

This comes out of the pcssendpoint class, which

which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth...
    soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth()

so you know what ?

I think this is a bug from outside of ptlib&opal. The default values for codec sizes in ptlib&opal are for a count of 2 buffers (unix) and 3 buffers(windows).


Indeed. I have submitted a temporary patch to Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it.

This patch will break with some hardware, even on Linux.

With the standard 8 kHz codecs, there is not more than 2-3 errors on 1 Mbyte of data using a two periods hw buffer and a 150 ms jitter buffer from Sweden to the echo server. I've added logging code to the alsa driver to show this. I have not been able to get any usable results using the 16 kHz codecs against 500 ekiga net (no sound at all...). If the jitter buffer is decreased to 50 ms there are more errors, but then the sound is so bad anyway that it's not a valid usecase.

Thinking about it, I can't really see why two or three periods should be a problem unless the jitter buffer is to small (or the system overloaded). And it's the user who sets the jitter buffer. I really think the defaut value should be smaller 2 (or 3) on Linux. Question is how to adjust this value if needed. Yet another "hidden" gconf variable? Is it needed, can this be handled by the jitter buffer?

Anyway, this is a way to get rid of 40-60 ms of latency on Linux, more on windows. I think it deserves to be thought of, it is a substantial gain. BUt bot until the release is out :-)


PS: I can now accept calls with the gtk message box. This used to crash.  DS


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]