[Bug 648359] baseaudiosrc: ringbuffer: segbase/segdone not updated when ring buffer cleared leads to incorrect timestamps

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #3 from Robert Swain <robert.swain at gmail.com> 2011-04-28 06:58:45 UTC ---
You are correct that next_sample is set to -1, however the following is used to
calculate the buffer timestamp before entering the slave mode switch:

    /* calculate the sequentially next sample we need to read. This can jump
and
     * create a DISCONT. */
    sample = gst_base_audio_src_get_offset (src);

[some reading that increments sample by the amount read]

  /* get the normal timestamp to get the duration. */
  timestamp = gst_util_uint64_scale_int (sample, GST_SECOND, spec->rate);
  duration = gst_util_uint64_scale_int (src->next_sample, GST_SECOND,
      spec->rate) - timestamp;



In gst_base_audio_src_get_offset ():

  /* assume we can append to the previous sample */
  sample = src->next_sample;

...

  /* get the currently processed segment */
  segdone = g_atomic_int_get (&src->ringbuffer->segdone)
      - src->ringbuffer->segbase;

  if (sample != -1) {

...

  } else {
    /* no previous sample, go to the current position */
    GST_DEBUG_OBJECT (src, "first sample, align to current %d", segdone);
    sample = ((guint64) (segdone)) * sps;
    readseg = segdone;
  }

Looking at the audio ringbuffer code, segbase/segdone are never reset during
the lifetime of the ringbuffer. When going down to READY and coming back up to
PLAYING with the pipeline the base_time is updated and so the running time has
been reset, but segbase/segdone were not reset meaning that the timestamp
calculated using the ringbuffer offset as noted in the code path above will
follow on from where it was before going down to READY. This means that the
running time is _earlier_ than the calculated timestamp and as such neither of
the two conditions quoted are hit in skew mode.

The audio ringbuffer segbase/segdone are only reset if the source element is
taken down to NULL, which is a current workaround. Wim has proposed that some
unit tests be implemented to study the behaviour such that we can then figure
out what the proper fix is.

There are certainly many different ways to fix this and it seems that the audio
ringbuffer code needs some love, but we could not decide as to what solution
was correct.

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