[Bug 702230] gst-plugins-base: spurious error from GstAlsaSrc

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #2 from David Svensson Fors <davidsf at axis.com> 2013-09-24 06:08:09 UTC ---
Created an attachment (id=255604)
 View: https://bugzilla.gnome.org/attachment.cgi?id=255604
 Review: https://bugzilla.gnome.org/review?bug=702230&attachment=255604

audioringbuffer: check if acquired in set_timestamp

I can reproduce the GST_ERROR reported by Sebastian Rasmussen. As explained in
his analysis, audioringbuffer_thread_func() in gstaudiosrc.c calls
gst_audio_ring_buffer_set_timestamp() at a point where buf->timestamps has been
set to NULL by gst_audio_ring_buffer_release() from another thread.

My suggestion is to report this case using a GST_DEBUG in
gst_audio_ring_buffer_set_timestamp(), not as a GST_ERROR. The
GstAudioRingBuffer has just been released by a concurrent thread, and to me it
seems best to not require that audioringbuffer_thread_func, as a user of the
GstAudioRingBuffer API, handles that case itself in a thread-safe way. It
should be no problem for the GstAudioRingBuffer to not save the timestamp when
the buffer has been released.

In the attached suggested patch the "acquired" flag is checked in
gst_audio_ring_buffer_set_timestamp(), for handling the case where the buffer
has been released. GST_OBJECT_LOCK is used for protecting object data.

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