[Bug 657076] New: [baseaudio/ringbuffer] may fail to provide running clock

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=657076
  GStreamer | gst-plugins-base | unspecified

           Summary: [baseaudio/ringbuffer] may fail to provide running
                    clock
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mnauw at users.sourceforge.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=194363)
 View: https://bugzilla.gnome.org/attachment.cgi?id=194363
 Review: https://bugzilla.gnome.org/review?bug=657076&attachment=194363

ringbuffer: start ringbuffer if needed upon commit

Consider some clip with very little audio (below a typical ringbuffer size).
In this case, while the ringbuffer is allowed to start upon changing to
PLAYING, it will never really start (since no new segment is needed, so no
wait_segment is called, which otherwise starts ringbuffer).

So, no advancing ringbuffer and no advancing clock, and then nothing much
happens really (no video rendering either etc).

Attached patch arranges to start ringbuffer upon commit.  While it may be
marginally less optimal (? in some cases ?) it makes sense to get going when
there is something to do (i.e. data) and really arranges for a running clock
which is often claimed to be provided.

Note this is a sort-of counterpart to a recent fix that had to arrange for
providing a running clock when going to PLAYING (after PAUSED) after EOS.
Both seem to stem from no longer starting the ringbuffer upon PLAYING, but only
allowing it to start, and it leads to wondering if that has provided more
benefit (which ?) than issues ...

-- 
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.