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? > Hi, 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 hack: //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 bad. 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... Cheers, -- Craig Shelley EMail: craig microtron org uk Jabber: shell jabber earth li
Attachment:
signature.asc
Description: This is a digitally signed message part