Hi Damien, > > while heavy duty testing (personal normal operation mode *ggg*) i did > > encounter the following issues: > > > > 1.) Video Plugins cannot be changed while in a call (i can modify > > whatever I wish *within* the same plugin, but I cannot switch live to my > > freshly plugged in cam once I have started the call sending MovingLogo) > > > 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 switch on a cam after starting the call would be better than having the FEATURE of stopping me from doing that.. > > 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) > > 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 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? > > 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* -- Best regards, Kilian
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil