Potential Error Case is Ignored by GstAudioRingBuffer
Submitted by Andrew
Link to original bug (#797334)
Description
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.