[Bug 657076] audioringbuffer: may fail to provide running clock

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #3 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2014-12-24 11:17:32 UTC ---
There are 2 stages/notions of starting here; starting the ringbuffer on the one
hand, and then really starting (uncorking) pulseaudio.  Note that pulsesink
does not really uncork when starting the ringbuffer.

The ringbuffer is started on EOS, but that need not help as such (in view of
the above).  However, there are some other steps in place to arrange for an
uncork when EOS or GAP is received.

So, in overall, this is not a problem as long as upstream sends EOS or GAP.
However, upstream (demuxer or whatever) may not be in a position (of knowing)
to send EOS (or GAP), e.g. in some (live) streaming situation.  And AFAIK, it
is not spec'ed (is it?) to always send (spam?) GAP in absence of data (GAP
being more a voluntary convenience in case of some sparse streams).

As such, if we are sure to send GAP in lots of (upstream) places, this is not a
problem.  But it seems more robust (and sort of user-friendly) to handle this
downstream in pulsesink, and really start/uncork when one would expect it (at
the very l(e)ast when receiving data), rather than to over-optimize with
potential drawbacks.

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