Re: [Ekiga-list] PTLIB alsa plugin status

[Alec Leamas <leamas alec gmail com>]

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:
> > > >         
> > > > > Hi,
> > > > >
> > > > > 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
> > >
> > > OpalAudioMediaStream::OpalAudioMediaStream(
> > >  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).
> > >
> > > Derek.
> > >
> > >       
> > Indeed. I have submitted a temporary patch to 
> > http://bugzilla.gnome.org/show_bug.cgi?id=572953. 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 :-)

--a

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

--a