[Bug 697723] New: Reset segdone when releasing audioringbuffer

[GStreamer (bugzilla.gnome.org)]

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

           Summary: Reset segdone when releasing audioringbuffer
    Classification: Platform
           Product: GStreamer
           Version: 1.0.6
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: visechelle at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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

Patch

In gstaudioringbuffer.c and in the function gst_audio_ring_buffer_release(),
segdone is not set to 0 whereas ringbuffer memory is freed and I guess it
should be the case.
I actually had a problem in the case of such a pipeline:

alsasrc ! ... ! udpsink

It happened (sometimes...) that after handling audio buffers, caps are set
again and gst_audio_base_src_setcaps() releases and acquires a new
audioringbuffer. Doing this, will stop the thread retrieving audio packets in
gstaudiosrc and then restart it when acquiring a new audioringbuffer. When the
thread will start it will wait for the ringbuffer to be started (this is done
in wait_segment() of gstaudioringbuffer()), in the mean time
gst_audio_ring_buffer_read() will be called and process the first buffers. If
there is no element creating a thread between alsasrc and udpsink, it happened
that udpsink blocked on sync waiting for the clock (generated by audiobasesrc)
to reach a value that it never reached.
To avoid such a case I reset segdone when releasing the audioringbuffer. When
calling gst_audio_ring_buffer_read(), no buffer are pushed as there is no data
in the audioringbuffer and wait_segment() is called starting the
audioringbuffer which will signal to the thread in gstaudiosrc to start filling
the audioringbuffer and data will be processed without risk of locks.

P.S.: in the provided patch, I also added initialization of segbase and segdone
as I did not find any initialization of these variables anywhere. I guess  the
compiler set them to 0.

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