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

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Wed Nov 22 13:01:57 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 #19 from Brian Cameron  2006-11-22 21:00 UTC -------
Created an attachment (id=77040)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=77040&action=view)
preliminary patch to fix performance issues


Padraig provided the attached patch to improve performance on Solaris.  I
haven't yet tested this to verify it works well, so I'd hold off on 
committing the patch until we test it some more.  I just wanted to attach
the patch for reference, comments, etc.  I'll follow up with a comment 
telling you how I find things work after testing.

 Before he wrote the patch he had the following comments:

I am using a segment size of 4410 and a segtotal of 20. have the lines
spec->segsize *=5;
spec->segtotal = 20;
in gst_sunaudiosink_prepare.

I have threied calling thr_yield without corcing the audio device to open
non-blocking.

The results seem to be better than you see but are not perfect.

I have worked my way through mu debug log and I see that after writing segments
0 and 1 to the audio device, new data is written to segment 0. Then after
segment 2 is written to the
audio device new data is written to segment 1. This happy situation of writing
segment n to the audio device and then writing  data to segment n-1 before
writing segment n+1 to the audio device containues for some time.

Then suddenly data stops being written to the segments in the ring buffer and
data continues to be written to the audio device which causes stuttering as
silent samples are eventually written.

I have not been ablt to determine why this is so. It looks like the call to
thr_yield sometimes does not cause the thread which writes data to the ring
buffer to be activated.

Be that it may, I would to like to see if we can implement a proper fix. I
believe that we need the function gst_ring_buffer_prepare_read to return FALSE
if the next segment has been filled with silence samples and has not had data
written to it since. 


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




More information about the Gstreamer-bugs mailing list