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 405451 - [alsasink] deadlocks when disconnecting USB Sounddevice
[alsasink] deadlocks when disconnecting USB Sounddevice
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.x
Other Linux
: Normal normal
: 0.10.12
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-02-07 17:35 UTC by Sebastien Bacher
Modified: 2007-02-15 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastien Bacher 2007-02-07 17:35:54 UTC
That bug has been opened on https://launchpad.net/ubuntu/+source/rhythmbox/+bug/81307

"Binary package hint: rhythmbox

Rhythmbox hangs when disconnecting the USB Audio device I'm currently playing music on .. I know, that's nothing one does all the day - but I'm switching often between PCI Sound and USB Sound.

Rhythmbox perhaps should detect error's with the playback and stop the current playback.

priority: low
...
I'm using Ubuntu Edgy
...
http://librarian.launchpad.net/6195384/gdb-rhytmbox.txt
Backtrace with debug symbols installied
..."
Comment 1 James "Doc" Livingston 2007-02-08 12:30:05 UTC
This looks like an alsasink bug, so re-assigning to GStreamer.

Just to confirm, do you see the same thing when using Totem or any other GStreamer-based media player?
Comment 2 self 2007-02-08 15:50:29 UTC
unfortunately I'm not able to say totem to play using my usb device .. it just plays sound via my build-in soundcard, even if I selected "USB Audio" for all types of output in gnome's audio preferences - so I can't verify if it's a gstreamer-bug :( 
Comment 3 Tim-Philipp Müller 2007-02-08 15:56:11 UTC
Looks at first glance like alsasink is trying to post an error message with the object lock held (which is going to deadlock, since both gst_element_message_new_*() and gst_element_post_message() will try to take the lock as well). Most likely a GStreamer bug.
 
Comment 4 Tim-Philipp Müller 2007-02-08 16:19:29 UTC
indeed, in gst_base_audio_sink_change_state() we take the object lock:
    ...
    case GST_STATE_CHANGE_PLAYING_TO_PAUSED:
      /* need to take the lock so we don't interfere with an
       * async play */
      GST_OBJECT_LOCK (sink);
      /* ringbuffer cannot start anymore */
      gst_ring_buffer_may_start (sink->ringbuffer, FALSE);
      gst_ring_buffer_pause (sink->ringbuffer);
      GST_OBJECT_UNLOCK (sink);
      break;
    ...
Comment 5 Wim Taymans 2007-02-15 11:59:53 UTC
        * ext/alsa/gstalsasink.c: (gst_alsasink_reset):
        Ignore errors in reset, these are not fatal. They also grab the element
        lock which is already taking when this function is called. Fixes
        #405451.