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

[Craig Southeren <craigs postincrement com>]

To all,

It is important to realise that comparing GM to other audio applications
such as RealPlayer is not really very useful. 

GM provides real-time audio delivery, that is, the audio is delivered
from end to end with as little delay as possible. Any buffering of the
audio stream would result in a noticeable lag in conversations. This
makes GM sensitive to both network traffic and CPU usage.

Network applications such as RealPlayer are not real-time. They can (and
do) buffer many seconds of data in order to provide a seamless replay
even when network traffic slows down the arriving packets. They can even
take advantage of large buffers in the sound hardware itself to reduce
the dependence on the host CPU.

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 :).

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.

This problem will tend to be self correcting, as when when packets start
arriving too late to be useful, they will be thrown away thus reducing CPU
usage.

This problem is going to occur regardless of what sound card hardware is
used, as OpenH323 uses very little hardware buffering in order to reduce
latency in the audio stream. 

This is quite a common problem with using general purpose processors for
real-time applications. I have seen other people suggest that this a
good reason for putting the entire RTP stack and codecs in the kernel,
but I think this is overkill personally :)

In any case, there are several ways to help this situation:

a) As suggested previously, the NPTL patches should help with faster
context switches

b) Increase the minimum jitter buffer size. The jitter buffer is the
buffer that OpenH323 uses to cope with inconsistencies in the incoming
network packets. While increasing this size will add lag to the
conversation, just one or two packets of extra buffering (30-60ms) will
not be noticeable and can make a dramatic difference to the audio
quality especially when network traffic goes up.

c) Increase the number of frames per packet in outgoing packets. This
will also slightly increase the lag in the conversation, but will also
reduce the sensitivity to context switch lag as more audio frames will
be processed for each switch.

d) Don't do compiles while talking :)

   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/