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 610413 - pulsesink: blocks in open() if audio device is in use
pulsesink: blocks in open() if audio device is in use
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-02-19 00:00 UTC by Tim-Philipp Müller
Modified: 2018-11-03 14:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add a watchdog to detect hangs waiting for free space (5.55 KB, patch)
2016-06-23 15:59 UTC, Vincent Penquerc'h
none Details | Review

Description Tim-Philipp Müller 2010-02-19 00:00:55 UTC
When e.g. the flash plugin is hogging the audio device, trying to play a movie in totem or with gst-launch-0.10 playbin2 will just preroll and hang before starting to play, because pulseaudio seems to be blocking in the open() call or whatever, waiting for the plugin to release the device.

Instead, pulsesink should post the appropriate RESOURCE BUSY error and get on with things (so that autoaudiosink can skip to the next audiosink and try that, like alsasink in this case).

Totem just hanging at the first frame without any explanation at all is not very nice.
Comment 1 Tim-Philipp Müller 2016-04-11 14:04:20 UTC
Still a problem:

 $ gst-launch-1.0 audiotestsrc ! alsasink device=hw:1 &

 $ gst-launch-1.0 audiotestsrc ! pulsesink
 (nothing happens after 'Setting pipeline to PLAYING ...')
 ... starts outputing audio as soon as you kill the first process..
Comment 2 Vincent Penquerc'h 2016-06-23 13:19:50 UTC
It's blocking in the first call to _commit, waiting for a signal that never comes. Best way out seems to be a timer when committing, and error if we can't finish the commit within a second or other appropriate time span. I don't see a _timed_wait version in pulse though, so it'd have to be another thread doing timer handling and calling _signal, which is a bit ugly.
Comment 3 Vincent Penquerc'h 2016-06-23 13:45:25 UTC
Not the first call, actually. A few calls happen, some audio is queued, but never flushed.
Comment 4 Vincent Penquerc'h 2016-06-23 15:40:06 UTC
I've got something that works, and errors out after a timeout. However, I've ust realized that since this happens after commit (and thus, in PAUSED or PLAYING), this can't be used for autoplugging, since I think that requires failing on NULL->READY ?
Comment 5 Vincent Penquerc'h 2016-06-23 15:59:15 UTC
Created attachment 330271 [details] [review]
add a watchdog to detect hangs waiting for free space

Here it is anyway.
Comment 6 GStreamer system administrator 2018-11-03 14:41:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/23.