[Bug 645961] New: [pulsesink] hangs when going from paused to playing near EOS

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=645961
  GStreamer | gst-plugins-good | git

           Summary: [pulsesink] hangs when going from paused to playing
                    near EOS
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mail at renestadler.de
         QAContact: gstreamer-bugs at lists.freedesktop.org
      GNOME target: ---
     GNOME version: ---


Created an attachment (id=184466)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=184466)
Test script to reproduce the issue

[This issue is a bit similar to bug #636886]

When pausing a non-live pipeline involving pulsesink during EOS rendering time
(gst_base_sink_wait_eos) and going back to playing, the pipeline hangs forever
waiting for EOS. This is easy to reproduce with a larger ringbuffer (of the
kind we like to use in mobile devices). I'm attaching a test script that
reproduces this with audiotestsrc ! pulsesink latency-time=100000
buffer-time=500000 for example.

The cause of the problem is that the pulsesink provided clock is frozen (time
doesn't continue). This leads to base_sink_wait_eos waiting forever because it
uses clock_id_wait. Time is frozen because the pa_stream remains corked here.
This is a side-effect of Wim's change to defer uncorking until there is actual
data to be written. Obviously that won't happen during or after EOS.

It seems this needs a fix to baseaudiosink as well as pulsesink itself. I'm
attaching two patches for illustration purposes; they fix the issue as far as
it can be triggered by the script but they are not perfect. First fix to
baseaudiosink changes it so that the ringbuffer is also started during
wait_eos/draining. This can be seen as an extension of Mark's fix for bug
#636886, which added this behavior for the time *after* EOS is rendered
(basesink->eos == TRUE).

Starting the ringbuffer however has no effect on pulsesink since this gets
deferred. Second patch changes that to detect the pending EOS situation there
as well, then uncorks right away to keep the clock running even without data.
Also, it seems pulsesink didn't check basesink->eos before, which makes me
wonder whether the fix for bug #636886 had any effect here(?)

Maybe someone has an idea how to implement those fixes in a bit more elegant
way (and how to eliminate remaining races in baseaudiosink).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.