[Bug 797334] New: Potential Error Case is Ignored by GstAudioRingBuffer

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797334

            Bug ID: 797334
           Summary: Potential Error Case is Ignored by GstAudioRingBuffer
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: astandley at linear-systems.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

In trying to debug issues behind Bug 797329
(https://bugzilla.gnome.org/show_bug.cgi?id=797329) it was discovered that an
error case seems to be completely ignored by the GstAudioRingBuffer.

default_commit 'skips' the writing of a segment to the output buffer when the
read pointers has surpassed the write pointer (diff < 0), but still advances
the write pointer by the segment size. The intention appearing to be that this
should advance the write pointer a segment ahead of the read pointer, and allow
the next segment to write.

The issue is that default_commit's return indicates that the full segment was
written, and fails to track this error internally. Thus, the potential error
state were the write pointer never catches up to the read pointer (and the
rendering is for all intents broken), appears to be undetectable.

* Due to no internal error tracking GstAudioRingBuffer will have no idea that
it has skipped the millionth segment in a row.

* Due to GstAudioRingBuffer indicating by it's return that full segment was
written and advancing the write pointer, higher level elements appear to have
no way of knowing a segment was drop. Thus they appear to have no way of
tracking how many segments have been successively dropped, and detecting if
this exceeds an error threshold.

I am sure that the error state is a rare one, and in this case caused by an
unrelated issue. However never detecting an error state in the pipeline seems
bad.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.