Re: [GnomeMeeting-list] How to fix sound choppy on CPU load?

[Craig Southeren <craigs postincrement com>]

On Thu, 6 Nov 2003 00:48:46 +0100 (CET)
"Mihai T. Lazarescu" <mihai email it> wrote:

..deleted

> > Appliciations such as Xine are even less useful for comparison. Not only
> > do they do extensive buffering, but they have no dependence on network
> > traffic (unless you are using NFS mounts :).
> 
> Recently there is a http://... input for xine... :-)

The comments on bufferring still apply.
 
> > GM does not require much overall CPU power (especially for high speed
> > processors), but maintaining real-time performance does require regular
> > chunks of CPU time for every incoming and outgoing packet. If the CPU is
> > being heavily used, GM will not be able to keep up with the incoming
> > packets in real-time, nor will it be to keep sending packets fast enough.
> > This will result in exactly what you are getting - choppy audio and
> > video at both ends.
> 
> I reopen my original question: would you agree that this
> effect should be alleviated (if not solved right away) by
> increasing the priority of the GM process?  My experiments
> show no noticeable difference while playing with GM process
> priorities up to -20.

Then obviously the problem is NOT with GM :)

I mean that seriously. If nicing GM does not change anything, then the
problem must be elsewhere. I suspect a priority inversion caused by the
fast GM talking to a slow "something else" Some things that come to
mind:

a) network usage. If the network interface is being hammered, then jitter
will go up and the effect will be much the same as lack of CPU.

b) sound card driver. If the data interface to the sound card driver
requires a lot of time on the I/O busses, then this will certainly
affect real-time performance.

c) video problems: if you are doing video at the same time as audio,
then perhaps video is slowing down GM too much. This is unlikely, as
video is handled by a seperate thread, but some video cards do require a
LOT of bus-time.

d) swapping: Frequest disk I/O caused by swapping will certainly
interfere with real-time performance.
 
> > a) ...the NPTL patches should help...
> 
> I used the workaround that helped in other situations,
> setting the environment variable LD_ASSUME_KERNEL=2.4.1,
> but no effect again.

OK
 
> > b) Increase the minimum jitter buffer size.
> 
> No effect in my case.

Interesting.
 
> > c) Increase the number of frames per packet in outgoing packets.
> 
> How can I do this?

I'm not familiar with GM, but there are options to adjust the number of
frames per packet in the capabilities advertised by OpenH323
applications. Perhaps Damien can help wth this?
 
> > d) Don't do compiles while talking :)
> 
> Avoiding that won't be a problem, :-) although I suspect niced
> compilations and prioritized GM should mitigate/solve it.

I would agree it should be possible to do this. I remember that my
single processor 466mhz Linux running a 2.2 kernel could easily do a
compile while I was using ohphone. I was using a Quicknet card, so the
network traffic and codec required minimum CPU time, and I never ran
XWindows.
 
> The problem is that I get audio silence for every *small*
> CPU intensive event, even opening/closing an rxvt produces
> a few fractions of a second of silence!  Worse when Mozilla
> renders a page (just text, no java or flash).  Not to mention
> spamassassin processing incoming messages, or xsetbg (niced
> to lowest priority) displaying a new background image, etc.

Try running X at a lower number of colours per pixel, such as 256
colours. The more bits per pixel, the more data has to be thrown around
on the I/O busses, and the less likely you are to get real-time
performance.

Also, try running without X entirely, by either using ohphone or
by using another machine as the X server to see what happens.

> I suspect that the GM users are not supposed to switch to
> single user to have proper audio... :-) Actually no, since it
> seems that no other users besides me experience this erratic
> behavior. :-(

There are also lots of users who do NOT experience this behaviour, so it
is by no means normal behaviour. I'm sure we can find out what is
causing it if we keep looking.

   Craig


-----------------------------------------------------------------------
 Craig Southeren, craigs postincrement com http://www.postincrement.com
 Post Increment - Software, Consulting and Services
 Co-founder of the only open source H.323 project
 Phone: +61 2 43654666   Fax: +61 2 43673140   Mobile: +61 417 231046
 ICQ: #86852844          MSN: craig_southeren hotmail com   
 GnuPG Public Key:  http://www.postincrement.com/pgp.txt
 Blog:              http://users.tpg.com.au/adsl87w7/blog/