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

["Mihai T. Lazarescu" <mihai email it>]

There is a new element: when the sound gets cut because of
heavy CPU load, the rate of "late" packets in the statistics
panel increases constantly (10-20-30% and counting) with
respect to an usual of < 0.5% or so.  When the CPU usage
returns to normal, the rate begins to constantly decrease,
eventually reaching the low level of usual operation.

Perhaps I did not mention before, but when my sound gets choppy,
the same happens to the sound I send to the other party.

As I mentioned, RealPlayer (another streaming audio player)
does not suffer from high CPU usage.

To sum up the data until now, with high (100%) CPU usage:

    * the audio and still image animation gets very choppy;

    * "late" packets rate increases dramatically;

    * nice level does not have any effect;

    * other audio players (xmms, xine, Real) or network
      transfers (wget) appear insensitive to high CPU usage;

    * same Gnomemeeting behavior on a different architecture
      (different CPU, network and audio cards, different
      audio drivers).

Does it make sense that the streaming decoder gets idle since
it stops receiving inbound packets?  Likewise, the other party
may stop receiving packets from me, not because data is not
encoded, but because the packets are not sent.

Now the reply to Johnny suggestions:

On Wed, 5 Nov 2003, Johnny Strom wrote:

> Well the Preemptible Kernel patch is an improvment for multimedia
> applications so that is one thing you could try

OK, it's something I will try.

> and then you could
> check if the X server is run with a nice value or not.

No nice, it has the default priority, like any other program.

> Anyway if you would like to test new snapshots of GM so can you find the 
> rpms here: http://av8.netikka.fi/~johnny/

They behave the same, no improvement in this regard (although
I like the changes from 0.98.5! :-)

Thanks again for your assistance.

Mihai