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

[Johnny Strom <jonny strom netikka fi>]

Hi all :)


Well I know there is an issue in 2.4.23 that I could trigger with
the bttv driver, but the problem is not in the bttv driver it is 
somewhere else in the kernel I get an oops and I can repeat it.

Well try to use 2.4.23-pre5, if that one works ok plus ALSA then
perhaps it is the same problem that I had but trigged bye an other driver.

This is just an idea.


Cheers Johnny






Damien Sandras wrote:
> 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*