GNOME Bugzilla – Bug 330586
Doesn't work if esd is enabled
Last modified: 2006-03-15 20:47:24 UTC
Please describe the problem: In Ubuntu Dapper, after a normal GNOME login, esd is started : 17986 ? Ss 0:00 /usr/bin/esd -terminate -nobeeps -as 5 -spawnfd 16 If I start ekiga, run the configuration druid, and test the sound settings (I chose ALSA), ekiga tells me that it cannot open the sound device. If I "killall esd", I can run the sound settings correctly. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
We already have #329015 about esd issues... I'm wondering if the problem really is on our side... the code handling esd in ekiga is so simple it seems incredible it can break!
There were some mismatches in the code that suspends ESD. It should be fixed. Notice that you must run the GNOME version for that. If you compiled the --disable-gnome version, then ESD support is not linked.
I can still see this in Ubuntu Dapper with ekiga 1.99.1. Some details : - ekiga is not compiled with --disable-gnome - when I log in, esd is started like that : 13309 ? Ss 0:00 /usr/bin/esd -terminate -nobeeps -as 5 -spawnfd 16 - if I "killall esd", it works. - I can reproduce it all the time. If it was fixed after 1.99.1 was released, could you please point me to the correct diff on http://cvs.gnome.org/viewcvs/ekiga/src/ so I could prepare an updated package for Ubuntu ? Thank you,
Can you try with latest CVS? Thanks.
It would be great if you could provide me with a diff, or at least explain which changes you'd like me to test : I ran into problems compiling the latest CVS because of unmet dependancies which aren't available on Ubuntu yet (PWLib and Opal). Thanks,
Sorry, I don't remember when it was last changed and all what was changed. Just upgrade Ekiga to the latest CVS version, it is simpler.
Ok, using the latest packages from snapshots.gnomemeeting.net, it still doesn't work.
What does "esdctl standbymode" report before a call and during a call? Does "esdctl standby" put ESD into standbymode ? Another user reported a similar problem. I suspect an ESD bug.
Before starting ekiga: ***lucas@yoway:~$ esdctl standbymode server is on autostandby ***lucas@yoway:~$ esdctl standby ***lucas@yoway:~$ esdctl standbymode server is on autostandby Also: ***lucas@yoway:~$ esdctl allinfo server version = 0 server format = 0x00000021 server rate = 44100 After starting ekiga, the server switches to "running" mode. When I make the call, I get "Impossible d'ouvrir un canal audio pour la reception audio" (in french locale) and then the server switches back to "standby" mode.
There must be something in the gnome libraries on UBUNTU that makes it switch to "running". If you run "esdplay somelongsound.wav", and then type "esdctl standby", does it stop playing the sound and put the server in "standby" mode?
> If you run "esdplay somelongsound.wav", and then type "esdctl standby", > does it stop playing the sound and put the server in "standby" mode? Yes
I really don't understand what could be wrong...
OK. Let's focus on something more specific : the sound test in the wizard (it's easier to test for me, there's the same problem, and maybe fixing the problem here will help fix it for calls.). I've built esd with debug support. In page 6 of the wizard, I choose Alsa. When I click on "Next", I get the following output in esd : :comms: [../clients.c, 337] paused=1, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [../clients.c, 186] :comms: [../clients.c, 208] ================================ :trace: [../clients.c, 249] Error encountered while accepting connection :trace: [ ../proto.c, 875] (06) client state 2. ---> rd [ ../proto.c, 898] req dat : 6, 20 = 20 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 919] (06) handling request 0, connect. :trace: [ ../proto.c, 174] (06) esd auth: key matches, auth ok. :trace: [ ../proto.c, 124] (06) same endian order. :trace: [ ../proto.c, 216] (06) connecting to sound daemon = 1 +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (06) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 6, 4 = 4 (12) (0x0c 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (06) client state 2. ---> rd [ ../proto.c, 898] req dat : 6, 20 = 20 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 919] (06) handling request 12, standby. :trace: [ ../proto.c, 174] (06) esd auth: key matches, auth ok. :trace: [ ../esd.c, 580] setting sound daemon to standby <--- wr [ ../proto.c, 273] stdby ok : 6, 4 = 4 (1) (0x01 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=2 :trace: [../clients.c, 186] :comms: [../clients.c, 208] ================================ :trace: [../clients.c, 249] Error encountered while accepting connection :trace: [ ../proto.c, 875] (05) client state 2. ---> rd [ ../proto.c, 898] req dat : 5, 20 = 20 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 919] (05) handling request 0, connect. :trace: [ ../proto.c, 174] (05) esd auth: key matches, auth ok. :trace: [ ../proto.c, 124] (05) same endian order. :trace: [ ../proto.c, 216] (05) connecting to sound daemon = 1 :trace: [ ../proto.c, 875] (06) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 6, 4 = 0 (12) (0x0c 0x00 0x00 0x00 ) :trace: [ ../proto.c, 948] (06) no more protocol requests for client :trace: [ ../proto.c, 989] (06) error handling request 12, standby. :trace: [../clients.c, 119] (06) closing client connection +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 5, 4 = 4 (13) (0x0d 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 2. ---> rd [ ../proto.c, 898] req dat : 5, 20 = 20 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 919] (05) handling request 13, resume. :trace: [ ../proto.c, 174] (05) esd auth: key matches, auth ok. :trace: [ ../esd.c, 599] resuming sound daemon <--- wr [ ../proto.c, 290] resum ok : 5, 4 = 4 (1) (0x01 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 5, 4 = 0 (13) (0x0d 0x00 0x00 0x00 ) :trace: [ ../proto.c, 948] (05) no more protocol requests for client :trace: [ ../proto.c, 989] (05) error handling request 13, resume. :trace: [../clients.c, 119] (05) closing client connection +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=0 :trace: [../clients.c, 350] doing nothing, pausing server. 2 connections are made to esd - the first one sets the server in standby mode - the second one resumes the server (sets it in running mode) Is ekiga making those two connections, just to test that esd is working ? If I run the test (clicking on "test settings"), I get this : :comms: [../clients.c, 337] paused=1, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [../clients.c, 186] :comms: [../clients.c, 208] ================================ :trace: [../clients.c, 249] Error encountered while accepting connection :trace: [ ../proto.c, 875] (06) client state 2. ---> rd [ ../proto.c, 898] req dat : 6, 20 = 20 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 919] (06) handling request 0, connect. :trace: [ ../proto.c, 174] (06) esd auth: key matches, auth ok. :trace: [ ../proto.c, 124] (06) same endian order. :trace: [ ../proto.c, 216] (06) connecting to sound daemon = 1 +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (06) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 6, 4 = 4 (12) (0x0c 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (06) client state 2. ---> rd [ ../proto.c, 898] req dat : 6, 20 = 20 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 919] (06) handling request 12, standby. :trace: [ ../proto.c, 174] (06) esd auth: key matches, auth ok. :trace: [ ../esd.c, 580] setting sound daemon to standby <--- wr [ ../proto.c, 273] stdby ok : 6, 4 = 4 (1) (0x01 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=1 :trace: [ ../proto.c, 875] (06) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 6, 4 = 0 (12) (0x0c 0x00 0x00 0x00 ) :trace: [ ../proto.c, 948] (06) no more protocol requests for client :trace: [ ../proto.c, 989] (06) error handling request 12, standby. :trace: [../clients.c, 119] (06) closing client connection +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=0 :trace: [../clients.c, 350] doing nothing, pausing server. :trace: [../clients.c, 303] paused, awaiting instructions. :comms: [../clients.c, 337] paused=1, samples=0, auto=600, standby=1, record=0, ready=1 :trace: [../clients.c, 186] :comms: [../clients.c, 208] ================================ :trace: [../clients.c, 249] Error encountered while accepting connection :trace: [ ../proto.c, 875] (05) client state 2. ---> rd [ ../proto.c, 898] req dat : 5, 20 = 20 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 919] (05) handling request 0, connect. :trace: [ ../proto.c, 174] (05) esd auth: key matches, auth ok. :trace: [ ../proto.c, 124] (05) same endian order. :trace: [ ../proto.c, 216] (05) connecting to sound daemon = 1 +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 5, 4 = 4 (13) (0x0d 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 2. ---> rd [ ../proto.c, 898] req dat : 5, 20 = 16 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 923] (05) need more data. +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 2. ---> rd [ ../proto.c, 898] req dat : 5, 4 = 4 (0x4e 0x44 0x4e 0x45 0x28 0x00 0x00 0x00 ...) :trace: [ ../proto.c, 919] (05) handling request 13, resume. :trace: [ ../proto.c, 174] (05) esd auth: key matches, auth ok. :trace: [ ../esd.c, 599] resuming sound daemon <--- wr [ ../proto.c, 290] resum ok : 5, 4 = 4 (1) (0x01 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 5, 4 = 0 (13) (0x0d 0x00 0x00 0x00 ) :trace: [ ../proto.c, 948] (05) no more protocol requests for client :trace: [ ../proto.c, 989] (05) error handling request 13, resume. :trace: [../clients.c, 119] (05) closing client connection +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=0 :trace: [../clients.c, 350] doing nothing, pausing server. Again, 2 connections (first one to standby, the other one to resume). And I get the "can't open device" error message. If, before testing the settings, I run : esdctl standby I get this : (normal) :comms: [../clients.c, 337] paused=1, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [../clients.c, 186] :comms: [../clients.c, 208] ================================ :trace: [../clients.c, 249] Error encountered while accepting connection :trace: [ ../proto.c, 875] (05) client state 2. ---> rd [ ../proto.c, 898] req dat : 5, 20 = 20 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 919] (05) handling request 0, connect. :trace: [ ../proto.c, 174] (05) esd auth: key matches, auth ok. :trace: [ ../proto.c, 124] (05) same endian order. :trace: [ ../proto.c, 216] (05) connecting to sound daemon = 1 +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=0 :trace: [../clients.c, 350] doing nothing, pausing server. :comms: [../clients.c, 337] paused=1, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 5, 4 = 4 (12) (0x0c 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 2. ---> rd [ ../proto.c, 898] req dat : 5, 20 = 16 (0xba 0x01 0x82 0xcb 0x09 0x67 0xa7 0xd9 ...) :trace: [ ../proto.c, 923] (05) need more data. +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=0, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 2. ---> rd [ ../proto.c, 898] req dat : 5, 4 = 4 (0x4e 0x44 0x4e 0x45 0x28 0x00 0x00 0x00 ...) :trace: [ ../proto.c, 919] (05) handling request 12, standby. :trace: [ ../proto.c, 174] (05) esd auth: key matches, auth ok. :trace: [ ../esd.c, 580] setting sound daemon to standby <--- wr [ ../proto.c, 273] stdby ok : 5, 4 = 4 (1) (0x01 0x00 0x00 0x00 ) +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=1 :trace: [ ../proto.c, 875] (05) client state 3. :comms: [ ../proto.c, 936] -------------------------------- ---> rd [ ../proto.c, 938] request : 5, 4 = 0 (12) (0x0c 0x00 0x00 0x00 ) :trace: [ ../proto.c, 948] (05) no more protocol requests for client :trace: [ ../proto.c, 989] (05) error handling request 12, standby. :trace: [../clients.c, 119] (05) closing client connection +mixer+ [ ../mix.c, 1017] refreshing mix functions +mixer+ [ ../mix.c, 896] ++++++++++++++++++++++++++++++++++++++++++ :comms: [../clients.c, 337] paused=0, samples=0, auto=600, standby=1, record=0, ready=0 :trace: [../clients.c, 350] doing nothing, pausing server. :trace: [../clients.c, 303] paused, awaiting instructions. But then, testing the settings works. Maybe it's a race condition, something like "if ekiga tries to open the device too fast after setting esd in standby mode, it fails." Also, I've found something that might explain why it doesn't work on Ubuntu, but works elsewhere : esd is started with "-as 5", which means it will wait for 5 seconds before terminating after the last request was processed (probably to avoid having to fork an esd process each time a request is made).
For reference: ***lucas@yoway:~$ cat /etc/esound/esd.conf [esd] auto_spawn=1 spawn_options=-terminate -nobeeps -as 5 spawn_wait_ms=100 # default options are used in spawned and non-spawned mode default_options=
Ive checked the code, Ekiga first puts ESD in standby, then it starts the test until you terminate it, then it resumes. Would ESD be too slow to release the device?
I tried to set spawn_wait_ms=10000 but it didn't change anything.
I had the same problem in the past. Will try snapshots soon.
(In reply to comment #13) > Also, I've found something that might explain why it doesn't work on Ubuntu, > but works elsewhere : esd is started with "-as 5", which means it will wait for > 5 seconds before terminating after the last request was processed (probably to > avoid having to fork an esd process each time a request is made). "-as 5" means it makes esd free audio device after 5 of inactivity.
So, simple test: removing "-as 5" make it work for me. Looks like an esound bug.
(In reply to comment #19) > So, simple test: removing "-as 5" make it work for me. Looks like an esound > bug. Ooops. Ignore this: esd suddenly disappeared...
I just retried again to "esdctl on", then run ekiga and its audio test... No issue here ! I even tried to run a few "esdplay /usr/share/sounds/phone.wav" just before and while I was running the test. All runs smoothly here !
I recompiled esd and added a sleep(1) in esd_proto_standby() after esd closed the device. Basically, this blocks the esdlib (and thus ekiga) during the sleep since it waits for an answer. It even works with usleep(5*1000*10) (which should be 50 ms) Doing this, I don't see the problem any more. This really looks like a race condition. I'm not sure if it's doable, but I propose this: if you can't open the device, please try to open it again every 10ms for say, 50ms. If it still doesn't work, give up and show the dialog.
> "-as 5" means it makes esd free audio device after 5 of inactivity. Yes, that's what I meant. esd keeps running with the device open, so ekiga HAS to ask esd to release it (set esd in standby mode). Some distributions might ship without -as 5, thus forking a new esd each time a sound is played. I don't really like "-as 5" either: it makes it difficult to use apps which aren't esd-aware.
(In reply to comment #21) > I just retried again to "esdctl on", then run ekiga and its audio test... No > issue here ! I even tried to run a few "esdplay /usr/share/sounds/phone.wav" > just before and while I was running the test. > > All runs smoothly here ! Yes, but with which parameters is esd started ? (see /etc/esound/esd.conf) If it's not started with -as, it's normal...
Here is some more information : => /etc/esound/esd.conf is : [esd] auto_spawn=1 spawn_options=-terminate -nobeeps -as 5 spawn_wait_ms=100 # default options are used in spawned and non-spawned mode default_options= => uname -a is : Linux hilbert 2.6.15-18-k7 #1 SMP PREEMPT Thu Mar 9 16:18:01 UTC 2006 i686 GNU/Linux => apt-cache show libesd0 | grep Version is : Version: 0.2.36-3ubuntu2 => apt-cache show esound | grep Version is : Version: 0.2.36-3ubuntu2 => cat /proc/cpuinfo is : processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : mobile AMD Athlon(tm) XP-M 2800+ stepping : 0 cpu MHz : 2133.737 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow bogomips : 800.32 There has to be a difference somewhere between our setups !
(In reply to comment #25) > There has to be a difference somewhere between our setups ! Maybe your computer is just faster than mine at releasing the device. It might be related to a different audio driver. My card is : 0000:00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 02) Are you sure that esd is still running when you start the test ? (check with ps x|grep esd) Vuntz, what's your audio controller ?
(In reply to comment #23) > > "-as 5" means it makes esd free audio device after 5 of inactivity. > > Yes, that's what I meant. esd keeps running with the device open, so > ekiga HAS to ask esd to release it (set esd in standby mode). Some > distributions might ship without -as 5, thus forking a new esd each > time a sound is played. > > I don't really like "-as 5" either: it makes it difficult to use apps > which aren't esd-aware. Nope. Other distributions don't use -as 5. But esd is not forked each time a sound is played since it's launched from gnome-session (or gnome-settings-daemon) and it waits for its last client to exit before exiting. So it's always running on other distributions.
0000:00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) I'm pretty sure this is a race condition and I only see my proposed solution as an easy fix.
Easy fix, indeed. Proper fix, definitely not. I'm hardly refraining to push that as a bug in esound and close that one :-/
(In reply to comment #29) > Easy fix, indeed. Proper fix, definitely not. > > I'm hardly refraining to push that as a bug in esound and close that one :-/ Well, we need to fix this using Vincent's proposed workaround, AND report this as an esound bug. Most distributions will release with the dirty workaround anyway to make ekiga work out of the box.
I don't like the dirty workaround.
(In reply to comment #31) > I don't like the dirty workaround. A lot of people won't like ekiga if it doesn't work for them. Please consider that: + the release will happen in two days + a workaround can easily be removed in the future
I will add a sleep of 100 ms for the release. Dirty workaround, but well. Please report a bug to ESD, I do not have time to do it. Thansk for debugging this!
What bothers me is that it's both a dirty workaround and it's not even sure it will be enough :-/
(In reply to comment #33) > I will add a sleep of 100 ms for the release. Dirty workaround, but well. > Please report a bug to ESD, I do not have time to do it. Thansk for debugging > this! Now it works randomly: sometimes it works, sometimes it doesn't. Please implement a loop as Vincent suggested, so it tries a bit harder.
No sorry. Implementing such a loop is uneasy and really crappy code. Moreover, it would require changing some parts of OPAL and PWLIB, which are not Linux-only. I won't add crappy code in them because of an ESD bug. Marking as NOTGNOME as the bug is not solved and as it is not an Ekiga bug. I hope somebody will report the problem to the ESD developers so that it get fixed. I will remove the 100ms delay as it doesn't work.
(In reply to comment #36) > No sorry. Implementing such a loop is uneasy and really crappy code. Moreover, > it would require changing some parts of OPAL and PWLIB, which are not > Linux-only. I'm not sure I understand how a sleep() is that easier compared to a loop. Could you please point me to the diff where you added the sleep() ? > I won't add crappy code in them because of an ESD bug. > > Marking as NOTGNOME as the bug is not solved and as it is not an Ekiga bug. I > hope somebody will report the problem to the ESD developers so that it get > fixed. Done since last sunday. Esound bug is http://bugzilla.gnome.org/show_bug.cgi?id=334478 . I also reported a bug against Ubuntu to ask for a change in esd configuration : https://launchpad.net/distros/ubuntu/+source/esound/+bug/34818
The sleep() is in the code that suspends ESD. The opening of the device is inside pwlib (or inside opal) as we are using pwlib plugins. Anyway, I have always been against introducing workarounds for other programs bugs. The sleep was acceptable, but a loop in opal or pwlib is certainly not acceptable.
*** Bug 331960 has been marked as a duplicate of this bug. ***