Re: [GnomeMeeting-devel-list] GM issues..

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

Le ven 26/12/2003 à 20:22, Kilian Krause a écrit :
> > Yes, that's a feature. You can change the device for a given plugin, but
> > not the plugin itself.
> 
> dunno what kinda *FEATURE* this shall be, but it sucks.. being able to

First of all, I will ask you to be polite and stop telling everything
"sucks", that will be a good starting point.

> switch on a cam after starting the call would be better than having the
> FEATURE of stopping me from doing that..

Sorry but I don't think it has a big interest. However, you are free to
implement whatever you like and submit patches. I'm currently rejecting
all new features that are not vital for the 1.00 release to be able to
release it in time.

> 
> > > 2.) ALSA IS *CRAP*... whatever is making this issue burst up, my PC
> > 
> > No, Linux is *CRAP*, not ALSA. (just kidding)
> 
> well, whatever.. as long as i don't have any console telling me what
> broke the other i cannot tell which one of them needs fixing.. but for
> now the situation is kinda suboptimal ;)
> 
> and i cannot go for 2.6 as the HPT374 i have doesn't load with 2.6 due
> to IRQ conflicts..  (so unless the hpt366 module gets fixed, i'll leave
> the workstation on 2.4.23 or maybe downgrade to the fine working 2.4.21,
> just to try if it was the new kernel version)
> 

2.6 is worse for me.

> > > freezes that hard when ending a call that i have to push the hardware
> > > reset button.. no other lifesign from local or remote possible 
> > > 
> > 
> > Are you sure it is ALSA? ALSA is usually very stable, but USB is not. I
> > think USB is the worse part of the Kernel.
> 
> how can i *KNOW* ... what i *CAN* tell is that with OSS-emu i can at

Just do tests with and without USB.

> least have calls and exit them (even if GM sometimes doesn't believe
> they *are* ended, but that's another issue)
> 
> > > Probably the new ALSA-fix within the alsa.so does break as I feared ..
> > 
> > That's technically not possible.
> 
> Well, then how come oss.so is not having the problem but alsa.so?
> 

Is it a proof of something? I don't think so. Now, if you think it is
the problem, why not reintroduce the Abort call and test?

> > > Or maybe the ALSA API doesn't "Abort" for some reason or something else
> > > happens that I cannot track down for I do not even see any Kernel Oops..
> > 
> > > 3.) OSS emu of ALSA is being disconnected from playback (not from
> > > recording -- funny that is) when the local CPU burst into 100% load for
> > > a splitsecond even.. (like launching Mozilla or stuff).. so the remote
> > > can still hear me fine, but i have nothing more being played..
> > > 
> > 
> > Just check the debug output to be able to determine why it happens. If
> > the device becomes unavailable, then it probably closes the stream,
> > which is a normal behavior. 
> 
> i will later run a GM -d 3 via ssh and then try to grab some debug (or
> at least try to get some debug info with oss.so)... let's hope there's
> some more valueable info in there than with the hard freeze of alsa *g*
-- 
 _      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