Red Hat Bugzilla – Bug 124264
rhythmbox hangs other programs while paused when using esd
Last modified: 2007-11-30 17:10:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.6)
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):
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.
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
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):
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:
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?