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

[Damien Sandras <dsandras seconix com>]

Le mer 05/11/2003 à 23:01, Mihai T. Lazarescu a écrit :
> 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.
> 

So it means the CPU usage influences the network operations.


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

That doesn't mean anything to me. RealPlayer is only streaming,
GnomeMeeting is doing far more :
a- it is capturing from the soundcard
b- it is capturing from the webcam
c- it compresses and sends over the network (like RealPlayer)
d- it receives audio and video
e- it decompresses them and plays the audio through the soundcard

a, b, d, and e are not done by an application like RealPlayer.

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

I suggest you to report the bug to RedHat, really, there is nothing we
can do at our level. make -j 2 here, CPU busy at 100%, harddisk busy at
100% and everything is normal.

Anyway, as Johnny said, the preemptible patch has been coded expressely
for the kind of problem you are describing, but that's a kernel thing,
not an user program thing :)


> 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
> _______________________________________________
> GnomeMeeting-list mailing list
> GnomeMeeting-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
-- 
 _      Damien Sandras
(o-     GnomeMeeting: http://www.gnomemeeting.org/
//\     FOSDEM 2003:  http://www.fosdem.org
v_/_    H.323 phone:  callto://ils.seconix.com/dsandras seconix com