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

On Fri, 2006-03-31 at 09:31 +0200, Damien Sandras wrote: 
> Hi Craig,
> There is a variable named "soundChannelBuffers" in src/opal/pcss.cxx.
> Just to make sure, can you try changing its value to 1 and to 3, 4, ...
> to see if it makes a difference without your patch or not?


I have not actually tested it, but I can see that this variable
eventually gets copied into storedPeriods within the pwlib alsa plugin.
Therefore this should eliminate my need to use the following override

  //Try to get a bigger buffer (this only seems to work for playback)
  //FIXME this is a hack, it should be done in opal, or somewhere else
  storedPeriods = 15;

I originally changed that value to 15, and it is all that is required to
eliminate the choppy playback. It makes me wonder that if so many people
are able to get away with a value of 2, my system must be really quite
I just tried it again with various values, and found that if using chrt
to set the priority of the ekiga process, this value can be left at 2,
without hardware audio dropouts. Otherwise without using chrt, it has to
be left at 15.

One thing that concerns me a little is that the Lost Packets, Late
Packets and Out of Order packets statistics remain solidly on 0.0%, and
yet I can hear the effects of loading on this Internet connection which
is shared with other machines.

Also, I think my kernel is a bit dodgy, on two occasions I have had a
hard lock when issuing the chrt command. It usually happens when the
command is issued as the the ekiga process is spawning its threads.

One final observation is that I have just this second noticed my X
server running with a nice value of -10. This is the likely cause of
some of my trouble. Investigating...


Craig Shelley
EMail: craig microtron org uk
Jabber: shell jabber earth li

Attachment: signature.asc
Description: This is a digitally signed message part

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