Red Hat Bugzilla – Bug 189940
ekiga freezes and has problems with sound and restarting
Last modified: 2018-04-11 04:14:43 EDT
Description of problem: I am having a number of problems with Ekiga: (1) I am trying to use Ekiga to make calls using a SIP provider (ViaTalk - it uses a SIP Proxy - not sure if that is important). I am able to register fine, and make a call, but when the call connects, the ekiga gui stops responding and there is no way to stop the call except killing ekiga. After this Ekiga will not restart - starting ekiga from the command line does nothing, it just sits there. Then when I try to logout of gnome, it just hangs - I have to ctrl-alt-backspace to get a black screen, but to login again I need to kill the GDM process. After logging in again, Ekiga will again function one time with the same behavior. I am attaching a file with the results of "ekiga -d 6 > ekiga.log.txt 2>&1" from the first time ekiga is run per gnome session. (2) Thinking that maybe the SIP provider particulars were the problem, I decided to try my ekiga.net SIP account and call the 500@ekiga.net test number. When I did this, ekiga told me that sound was not working and disabled sound even though no other program I can think of (besides gnome) was using sound. Even stranger, I was able to play system sounds (e.g. the ring tone) from the Ekiga Preferences dialogue. Note that ekiga does not complain about the sound problem when using the ViaTalk account (perhaps it freezes first?). This sound problem is reminiscent of what happened when I tried to use the X-lite (aka Xten) softphone. It says on startup that /dev/dsp could not be opened and suggests looking at lsof /dev/dsp to see if other applications are using the sound system, but lsof /dev/dsp gives nothing. Version-Release number of selected component (if applicable): ekiga-2.0.1-1 How reproducible: always Steps to Reproduce: 1.start ekiga 2.try something 3. Actual results: Hangs or sound doesn't work. Expected results: Should work. Additional info: Attaching file with some ekiga debugging output. I didn't see anything particularly useful, but here goes anyway.
Created attachment 128230 [details] results of ekiga -d 6
I ran ekiga through gdb one of the time that it did nothing - i.e. ekiga on the command line does nothing just sits there. Here is the result: $ gdb ekiga GNU gdb Red Hat Linux (6.3.0.0-1.122rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/ekiga Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x821000 [Thread debugging using libthread_db enabled] [New Thread -1208453456 (LWP 3759)] [New Thread -1210553440 (LWP 3762)] [New Thread -1210819680 (LWP 3763)] Program received signal SIGINT, Interrupt. [Switching to Thread -1208453456 (LWP 3759)] 0x00821402 in __kernel_vsyscall () at /usr/include/ptlib/object.h:1380 1380 /usr/include/ptlib/object.h: No such file or directory. in /usr/include/ptlib/object.h (gdb) thread apply all bt Thread 3 (Thread -1210819680 (LWP 3763)): #0 0x00821402 in __kernel_vsyscall () at /usr/include/ptlib/object.h:1380 #1 0x00acc7ae in __lll_mutex_lock_wait () at /usr/include/ptlib/object.h:1380 #2 0x00ac916c in _L_mutex_lock_70 () at /usr/include/ptlib/object.h:1380 #3 0x00ac8fb8 in pthread_mutex_lock () at /usr/include/ptlib/object.h:1380 #4 0x05a0281c in gdk_threads_leave () at /usr/include/ptlib/object.h:1380 #5 0x05a027a0 in gdk_threads_enter () at /usr/include/ptlib/object.h:1380 #6 0x080b9738 in GMManager::OnGatewayIPTimeout (this=0x9f313e8) at endpoints/manager.cpp:1998 #7 0x080bde15 in GMManager::OnGatewayIPTimeout_PNotifier::Call ( this=0x9f31c68, note=@0x9f3184c, extra=1) at endpoints/manager.h:781 #8 0x080be1ba in PNotifier::operator() (this=0x9f31858, notifier=@0x9f3184c, extra=1) at /usr/include/ptlib/notifier.h:99 #9 0x046f8de1 in PTimer::OnTimeout () at /usr/include/ptlib/object.h:1380 #10 0x046fa939 in PTimer::Process () at /usr/include/ptlib/object.h:1380 #11 0x046faa92 in PTimerList::Process () at /usr/include/ptlib/object.h:1380 #12 0x046e940e in PHouseKeepingThread::Main () at /usr/include/ptlib/object.h:1380 #13 0x046e5c09 in PThread::PX_ThreadStart () at /usr/include/ptlib/object.h:1380 #14 0x00ac73b6 in start_thread () at /usr/include/ptlib/object.h:1380 #15 0x0090733e in clone () at /usr/include/ptlib/object.h:1380 ---Type <return> to continue, or q <return> to quit--- Thread 2 (Thread -1210553440 (LWP 3762)): #0 0x00821402 in __kernel_vsyscall () at /usr/include/ptlib/object.h:1380 #1 0x00aca48c in pthread_cond_timedwait@@GLIBC_2.3.2 () at /usr/include/ptlib/object.h:1380 #2 0x046e6b6a in PSyncPoint::Wait () at /usr/include/ptlib/object.h:1380 #3 0x05099f8f in OpalManager::GarbageMain () at /usr/include/ptlib/object.h:1380 #4 0x0509f175 in OpalManager::GarbageMain_PNotifier::Call () at /usr/include/ptlib/object.h:1380 #5 0x080be1ba in PNotifier::operator() (this=0x9f32054, notifier=@0x9f32000, extra=0) at /usr/include/ptlib/notifier.h:99 #6 0x046f7055 in PSimpleThread::Main () at /usr/include/ptlib/object.h:1380 #7 0x046e5c09 in PThread::PX_ThreadStart () at /usr/include/ptlib/object.h:1380 #8 0x00ac73b6 in start_thread () at /usr/include/ptlib/object.h:1380 #9 0x0090733e in clone () at /usr/include/ptlib/object.h:1380 Thread 1 (Thread -1208453456 (LWP 3759)): #0 0x00821402 in __kernel_vsyscall () at /usr/include/ptlib/object.h:1380 #1 0x00accb8b in __read_nocancel () at /usr/include/ptlib/object.h:1380 #2 0x007b4a80 in esd_send_auth () at /usr/include/ptlib/object.h:1380 #3 0x007b4ecf in esd_open_sound () at /usr/include/ptlib/object.h:1380 ---Type <return> to continue, or q <return> to quit--- #4 0x080a5193 in gnomemeeting_sound_daemons_suspend () at devices/audio.cpp:96 #5 0x080b0877 in GnomeMeeting::DetectDevices (this=0x8131a20) at endpoints/ekiga.cpp:253 #6 0x0809910b in main (argc=1, argv=0xbfaaaad4, envp=0x720f8afe) at gui/main.cpp:4506 #7 0x008547e4 in __libc_start_main () at /usr/include/ptlib/object.h:1380 #8 0x0806cbf1 in _start () at /usr/include/ptlib/object.h:1380 (gdb)
You seems to use the enlightment sound daemon and the OSS sound system, use the ALSA audio plugin instead (Edit->Preferences->Devices->AudioDevices), there is tons of problems in the legacy OSS/ESD systems. Change this restart ekiga or even better the full desktop and report. Daniel
As far as I know, I am using ALSA. Under Edit->Preferences->Devices->AudioDevices (in Ekiga), the only option is ALSA for the audia plugin. I ran ekiga again, this time after rebooting and it still has similar problems. The only thing I can think of that is using ESD is gnome itself - under the gnome preferences for Sound, there is an option "Enable sound system startup (ESD)". This option is checked currently. Unchecking it and then killing the /usr/bin/esd process (that gnome starts?) brings Ekiga back to life. But if I uncheck this option, gnome cannot play sounds. I don't think I really need this, but it seems strange that you would have to give up gnome sound to use other audio applications. Is this conflict a gnome problem or a ekiga problem?
Mine is unchecked. ESD has mutiple use problems. Without ESD, ekiga, rythmnbox and various audio programs cohabit nicely for me. IMHO ESD is the culprit. Daniel
OK, it appears that this is the case. But I reiterate that this means you can't use gnome sounds (i.e. no music when you log on). While most people consider this stuff annoying anyway, it looks kind of weak that this doesn't work. Should this bug be forwarded on to some other package? As far as I can tell, the only thing that requires esound (ESD) on my machine is libgnomeui.
This bug has quite a history: http://lists.debian.org/debian-user/2003/12/msg04021.html They suggest several sollutions (in 2003!).
yeah ESD has a not so glorious track :-\ Ideally that should be reported upstream, but I guess it's the case for a few years, what is surprizing is that Gnome as shipped still relies on it, I have no idea why ! This bug should either be reaffected or labelled as a duplicate of an existing bug on esd or closed. Honnestly that's not really an Ekiga problem this bug has been plaguing the whole desktop for a long time ... Daniel
Shouldn't this bug be closed as ESD is officially dead in Fedora 8 and upwards? Fedora Core 5 is not supported anymore. Not that the situation with ekiga and sound daemons would be any better (see bug 303951) though ;-).
and bug 369631 which is duplicate of the bug 303951
Do these problems still occur with a newer version of ekiga/Fedora?
I am still experiencing this issue with Ekiga in Fedora 8 and current ekiga (ekiga-2.0.11-2.fc8) with all updates applied. It's quite frustrating to call sip:500@ekiga.net and not only get no sound back but to have the ekiga app stop responding _completely_
Is this still an issue in Fedora 9?
I don't have F8 anymore where I would test it. Reporter, what do you think?
Closing as no response from the user and F-8 about to go EOL. If its still an issue can you retest with F-9 or later.