From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.6) Gecko/20040518 Firefox/0.8 Description of problem: If you are using esd output for sound events and gaim has some sounds queued up which have not been sent when you quit it will hang with a greyed out window until such a time that those sounds are played. Version-Release number of selected component (if applicable): gaim-0.77-7 How reproducible: Always Steps to Reproduce: 1. Start gstreamer-properties and set the input and output sinks to ESD 2. Start gaim go to Tools -> Preferences | Sounds and change the method to ESD 3. Start rhythmbox and play some music 4. While the music is still playing press the pause button 5. Go back to gaim and do something that generates a sound event (on my setup a sound is generated each time a message is sent to me so I open a chat to myself and send a few messages). No sounds will be heard. 6. In the main gaim window go to Buddies -> Quit Actual Results: All open windows are still displayed but the contents of widgets is not drawn so everything is grey and white. Expected Results: All gaim windows to close and for the app to exit. Additional info: Unpausing rhythmbox will play the queued up gaim events all at once and let gaim exit. Now it could be argued that this is actually a bug in rhythmbox / gstreamer since I have seen some other selfish behaviour. rhythmbox has a nasty habit of not actually freeing up the sound device when music is paused. Thus if I have another app that plays sounds (e.g. totem) that doesn't use esd, then once I have started playing music in rhythmbox the only way to let the other app play sounds is to quit rhythmbox entirely.
make sure esd is actually running.
Yup esd is running (it was started by rhythmbox afaict). I was also under the impression that gaim would start an esound as needed if it wasn't already running.
I have the same problem. It's not just gaim though, if you enable event sounds, anything that queues a sound (like starting a new application) will be blocked until you unpause rhythmbox.
I can confirm comment #3. I enabled sound events, paused rhythmbox, tried to pop up an about box in Evolution and wound up hanging Evolution. The question now becomes where to punt this bug off to. Is it a bug in rhythmbox, gstreamer or esound? I'm guessing esound...
Ok using totem with the esound plugin (not as easy as it sounds) I can pause without causing the blocking that rhythmbox does so I'm going to punt this over to rhythmbox.
Reassigning to Colin Walters (since that is who most of the other rhythmbox bugs are assigned to). Changing title. I hope this is right and I apologise for getting the wrong component.
1)gaim won't try to start esd (at least not directly) 2)i don't know if libao does (thus if libao does, gaim does try to start it indirectly) 3)all sound events in gaim except the "command" option go throug libao.
Changing title agian to make a bit more sense.
This maybe fixed in gst-plugins 0.8.2. Here's a quote from http://planet.gnome.org/news/ for June 23, 2004: 2004-06-13 Jan Schmidt * ext/esd/esdsink.c: (gst_esdsink_change_state): * ext/esd/esdsink.h: Close the esd connection on pause, because esd will just wait - blocking all other esd clients indefinitely.
If so, I'd like to nominate gst-plugins for an updating in FC2 (bug 125270) since it will fix gstreamer ocassionally failing to open the audio when using alsa ( bug 119958 ) and also possibly fix rhythmbox hanging other programs when using esd (this bug).
This bug should be fixed in these RPMs: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/i386/gstreamer-0.8.3-2.i386.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/i386/gstreamer-plugins-0.8.2-2.i386.rpm Please test!
That fixed it! No problems with pausing and esd on my system now.
Yup, the testing packages fix the problem (but added a dependency on libmusicbrainz that didn't used to be there). Resolve as FIXED?
Closing, thanks.