Re: [GnomeMeeting-devel-list] Choppy Audio / Audio Dropout

[Michael Rickmann <mrickma gwdg de>]

Hello,
the description of symptoms quite well fits what I have observed with the 
WIN32 port on a Centrino system. In additioin Audio setup on that machine 
remains choppy for me, regardless whether I use the builtin device or USB 
audio.
Regards
Michael

On Thursday 30 March 2006 13:09, Damien Sandras wrote:
> Hi,
>
> I'm interested in a patch, then I can see with Craig if we can submit it
> to CVS.
>
> Le jeudi 30 mars 2006 à 11:34 +0100, Craig Shelley a écrit :
> > Hello list,
> >
> > I am new to this list, so please forgive me if I am barging in.
> >
> > I have been using ekiga 2.0.1 for a couple of weeks now, and will
> > continue to do so because I think this is an excellent piece of
> > software, Well Done!
> >
> > On my system I have been experiencing gaps and clicks in the audio while
> > in a call. This tends to occur while graphics operations are happening,
> > eg when switching between windows, or dragging windows around.
> >
> > After much searching on the net, and on mailing lists, I found people
> > describing similar problems, and it seems that 2.6 kernels, certain
> > graphics drivers (eg radeon), and low latency audio don't mix too well.
> > I have also tried all the usual stuff like changing PCI latencies,
> > interrupt priorities, and changing the real-time scheduling attributes
> > of the ekiga process.
> >
> > After a lot of testing, I came to the conclusion that the dropouts in
> > the audio were occurring because the ekiga process, under slight load
> > conditions, was not delivering the audio on-time, and not reading the
> > audio on-time.
> >
> > Looking more closely at what was going on in pwlib, I could see the
> > buffer time was something quite small like 40mS. On my system, in order
> > to eliminate the dropouts on audio playback, this had to be increased to
> > 300mS.
> > This solved the problems on audio receiving audio, but the audio from my
> > mic was still choppy with slight CPU load. Unfortunately, it wasn't just
> > a case of increasing the buffer size for recording because for some
> > reason alsa would only allow 2 periods in the record buffer. Therefore a
> > separate buffer thread was required in order to fix the recording
> > problems.
> > The buffer thread uses high priority realtime scheduling (SCHED_FIFO),
> > and seems to have been quite successful in completely solving the
> > problem with choppy recording.
> >
> > At the moment, I am testing this mod as a proof-of-concept fix, and all
> > seems well so far.
> > I appreciate that the problems I have been encountering are most likely
> > related to hardware/drivers, and the mods I have been doing are all
> > within pwlib source, and not ekiga or opal.
> >
> > If anyone is interested, let me know and i'll post the code/patch, but I
> > must warn you, this is a real hack, the code is very very bodgey.
> >
> > Regards,
> >
> > _______________________________________________
> > Gnomemeeting-devel-list mailing list
> > Gnomemeeting-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list