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 740385 - pulsesink does not recover from the pulseaudio server dying
pulsesink does not recover from the pulseaudio server dying
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.4.4
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-11-19 18:28 UTC by james.hodapp
Modified: 2018-11-03 14:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description james.hodapp 2014-11-19 18:28:55 UTC 
Steps to reproduce:

1. Start playback of an mp3 on a platform that uses pulsesink by default:
  GST_DEBUG=*:3 gst-launch-1.0 playbin uri=file:///music/my.mp3 audio-sink='pulsesink'
2. kill -9 `pidof pulseaudio`
3. Notice that playback stops and the following errors are observed:

0:00:40.970599079 20926 0xb1c2df80 WARN                   pulse pulsesink.c:1752:gst_pulseringbuffer_commit:<audio-sink> error: pa_stream_writable_size() failed: Connection terminated
0:00:41.311085079 20926   0x64f9a0 WARN                   pulse pulsesink.c:413:gst_pulsering_is_dead:<audio-sink> error: Disconnected: Connection terminated

Expected results:

1. pulsesink tries to reconnect to the pulse server and recreate the pa_context.
Comment 1 Reynaldo H. Verdejo Pinochet 2014-11-20 12:30:24 UTC 
What if the server is never restarted? Would the expected
behavior include somewhat of a sane timeout for this
situation?
Comment 2 james.hodapp 2014-11-20 15:01:20 UTC 
Yes I think that's reasonable. I would say 3-5 seconds of trying to reconnect should be sufficient. For Ubuntu, pulseaudio gets respawned immediately (less than 1 second) via Upstart.
Comment 3 Arun Raghavan 2014-11-23 07:57:20 UTC 
In terms of code, might be easier to have a number of retries, rather than something time-based.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2015-01-19 09:45:35 UTC 
Right now the app would receive the error message on the bus. Maybe we can do the following. 

Add new properties with the number-of-retries. If it is 0 we post the error, like now. If it is > 0, we post an warning message instead of the error and do the retries, for each retry we wait 1 second (or do we need another property here).
When the final retry fails we post an error. If this sounds good, I'd go with a default of 3 for number-of-retries. This changes the current behavior, but I think it actually improves the case for the user.
Comment 5 GStreamer system administrator 2018-11-03 14:56:18 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/144.