Re: [GnomeMeeting-devel-list] Very bad sound with 2.6.0

[Damien Sandras <damien sandras it-optics com>]

I have thought to a few more tests :
- Try to see if the problem occurs only when you are in a call, or also
when you are testing the sound configuration with the configuration
assistant
- Try to see if cat /dev/dsp > /dev/dsp also gives broken sound when
there is disk and/or CPU activity

That will permit determining if the problem really is with the sound
hardware. I have some doubts as I don't have the problem here with the
same chip and 2.6. However, I have other problems, but that's another
story ;)

Le sam 20/12/2003 à 17:36, Christian Meder a écrit :
> On Sat, 2003-12-20 at 17:13, Stefan Bruens wrote:
> > Am Samstag, 20. Dezember 2003 16:49 schrieb Christian Meder:
> > > On Sat, 2003-12-20 at 11:29, Johnny Strom wrote:
> > > > Hello
> > > >
> > > >
> > > > Is seems like the sound is so bad in Gnomemeeting plus OSS driver
> > > > (es1371) in the 2.6.0 kernel that one can't hear what they say in the
> > > > other end (Note it is the same in bouth directions).
> > > >
> > > > Have someone else tested this?
> > >
> > > Hi,
> > >
> > > I took the gnomemeeting regression from 2.4.2x to 2.6.0-testx (and up)
> > > to the linux-kernel list yesterday. Search for the gnomemeeting thread
> > > in
> > >
> > > http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/index.html
> > >
> > > I won't recap it all but I tried lots of different scenarios ALSA and
> > > OSS, gnomemeeting and gnomemeeting-cvs, Con's scheduler and Nick's
> > > scheduler, etc. (see thread) and I never got the same gnomemeeting
> > > quality I get in 2.4.2x under any kind of CPU load other than
> > > gnomemeeting.
> > >
> > > Probably it would help if Damien would review the thread and add any
> > > missing gnomemeeting specific information which could be relevant to
> > > this phenomenon. Specifically if there are any thread tricks
> > > gnomemeeting is using because that's an area 2.6 is differing from 2.4.
> > >
> > >
> > > 			Christian Meder
> > 
> > IIRC there was some problem with openoffice and sched_yield(), and as pwlib 
> > uses sched_yield too ...
> > 
> > Sorry, I have no time nor enough experience with schedulers to look into this 
> > myself.
> 
> Ok. You're right.
> 
> The code in pwlib
> 
>   if (errno == EINTR || errno == EAGAIN) {
>     if (++retry < 1000) {
> #if defined(P_RTEMS)
>       sched_yield();
> #else
>       usleep(10000); // Basically just swap out thread to try and clear
> blockage
> #endif
>       return TRUE;   // Return value to try again
>     }
>     // Give up and assert
>   }
> 
> does look similar to the Openoffice problem "busy looping on
> sched_yield() considered harmful". Although I've got no idea if it's
> really the problem here. 
> 
> 
> 
> 			Christian
-- 
 _      Damien Sandras
(o-     
//\     It-Optics s.a.
v_/_    GnomeMeeting: http://www.gnomemeeting.org/
        FOSDEM 2004:  http://www.fosdem.org
        H.323 phone:  callto:ils.seconix.com/dsandras seconix com