[gstreamer-bugs] [Bug 360673] Stuttering with SunAudio Sink

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Wed Nov 8 07:29:14 PST 2006


Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=360673

  GStreamer | gst-plugins-base | Ver: HEAD CVS





------- Comment #12 from Brian Cameron  2006-11-08 15:28 UTC -------

More comments from Padraig:

I had a look at the use of buf->waiting and this is what I see:

The function gst_ring_buffer_commit writes samples to the ring buffer until the
ring buffer is filled up. When this occurs the function wait_segment is called
and sets buf->waiting to 1.

This causes the write thread which was waiting in audioringbuffer_thread_func
to be woken up. The reason that audioringbuffer_thread_func had been waiting is
that gst_ring_buffer_prepare_read had returned FALSE.

When a buffer is written to the audio device the function
gst_ring_buffer_advance is called. This sets buf->waiting to 0 which allows
data to be written to the ring buffer. The thread which writes data to the ring
buffer wakes up and fil sup the ring buffer again and sets buf->waiting to 1.

The variable buf->waiting is set when the ring buffer fills up and so prevents
the thread which writes to the ring buffer from overwriting samples which have
not been written to the audio device.

There does not seem  to be a similar mechanism to prevent the thread which
writes samples to the audio device from reading segments in the ring buffer
which have not been written.

If there were I would expect gst_ring_buffer_prepare_read to return FALSE other
than at the beginning. This function should return FALSE if there is no data in
the ring buffer but there
does not seem to be a way to determine that.

It looks like there is an assumption that the thread which writes data to the
audio device will yield the CPU to allow the thread which writes to the ring
buffer to run but there is nothing to make that happen.

As an experiment try adding a call to thr_yield to the function
audioringbuffer_thread_func in gstaudiosink.c after the loop which writes data
to the audio device.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email




More information about the Gstreamer-bugs mailing list