After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 566843 - [pulse] Terminating an audio stream hangs the application
[pulse] Terminating an audio stream hangs the application
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.3
Other Linux
: Normal major
: 0.10.14
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-01-06 23:16 UTC by Aaron Bockover
Modified: 2009-01-29 13:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Aaron Bockover 2009-01-06 23:16:50 UTC
Migrating this bug from downstream/openSUSE:
https://bugzilla.novell.com/show_bug.cgi?id=395001

Important information from various comments pasted below:

---

<Michael Meeks>

I use pavucontrol while banshee is playing; right click and terminate the
stream.

Unfortunately - that hangs banshee: - of course the strace of banshee only
shows the normal mono 'busy' loop (sigh):

[pid 11643] clock_gettime(CLOCK_REALTIME, {1211970455, 569396653}) = 0
[pid 11643] futex(0xb7950110, FUTEX_WAIT_PRIVATE, 7321, {0, 99603347}
<unfinished ...>
[pid 11631] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid 11631] gettimeofday({1211970455, 669160}, NULL) = 0
[pid 11631] futex(0xb7950f4c, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 11631] clock_gettime(CLOCK_REALTIME, {1211970455, 669234481}) = 0
[pid 11631] futex(0xb7950f68, FUTEX_WAIT_PRIVATE, 7251, {0, 99765519}
<unfinished ...>
[pid 11643] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid 11643] gettimeofday({1211970455, 669322}, NULL) = 0
[pid 11643] futex(0xb79500f4, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 11643] clock_gettime(CLOCK_REALTIME, {1211970455, 669395535}) = 0
[pid 11643] futex(0xb7950110, FUTEX_WAIT_PRIVATE, 7323, {0, 99604465}
<unfinishe

unclear how to debug further.

---

<Aaron Bockover>

Now I see the hang, but it seems pretty corner case to me. The idea of
terminating streams is a horrid one to me from anywhere outside the
application. 

Furthermore as we use "autoaudiosink" in GStreamer, I'm not sure we should be
handling anything explicitly in Banshee. The pipeline should just go into the
NULL/READY state.

...

Totem and Rhythmbox exhibit the same behavior. This really seems to be a bug in
GStreamer (pulsesink).
Comment 1 Jan Schmidt 2009-01-06 23:48:31 UTC
slomo committed code for a very similar bug yesterday:

2009-01-05  Sebastian Dröge  <sebastian.droege@collabora.co.uk>

        * ext/pulse/pulsesink.c: (gst_pulsesink_destroy_stream):
        Don't wait for the pulse mainloop when destroying the stream.
        Fixes a deadlock when the pulsedaemon goes away while pulsesink
        is PLAYING. Fixes bug #556986.

Maybe that fixes this different variant of 'the daemon goes away' for you too?
Comment 2 Sebastian Dröge (slomo) 2009-01-29 13:35:10 UTC
I can't reproduce the issue anymore with the latest version of the pulse plugin in GIT... should be fixed in 0.10.14.