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

[GStreamer (bugzilla.gnome.org)]

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 #2 from Brian Cameron  2006-10-19 19:21 UTC -------
Created an attachment (id=75034)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=75034&action=view)
image showing graphical performance data for GStreamer running on Solaris


I ran the Sun Studio collect program to collect performance information so I 
could see where GStreamer seems to be spending its time.  I've attached a
screenshot of the analyzer GUI program running, which shows a timeline of 
where the CPU is spending its time.  You can see that there are 5 threads and
this might highlight what is going on.  I'll give some details of each of the
5 threads, to explain what the screenshot is showing:

Thread 1: This thread is the main thread.  You can see at the beginning it is
          doing all the work and then seems to go into poll state.

Thread 2: This thread seems to be used just in one place, near the end of the
          run.  Seems to be a call to gst_system_clock_async_thread. 

Thread 3: This thread seems to be called a lot.  Seems to be where
          g_thread_pool_thread_proxy is calling gst_task_func, then 
          gst_pad_push, gst_pad_chain_unchecked.  This seems to eventually
          call g_atomic_int_get, which then calls pthread_mutex_lock.

Thread 4: Calls to write

Thread 5: Just used once near the beginning.  _lwp_start calls _thr_setup, 
          calls g_thread_create_proxy, etc.

Not sure if this adds any information.  Though I wonder if something weird is
going on since thread #3 seems to be eating up all the time and the
"stuttering"
effect of thread 4 could correspond to the fact that this thread is only
invoked every 4 seconds which corresponds with the stuttering behavior.
Perhaps thread #3 is getting stuck in mutex_locks and preventing thread #4 
from being able to be called as often as it needs?

The fact that thread #3 is spending time in the pad logic makes me curious.
I would think GStreamer would figure out the plugin pads once at the beginning
and not need to spend so many CPU cycles dealing with the pads, though perhaps
I don't understand what is going on here.

Perhaps this "stuttering" behavior is caused by a slight difference in the
way threads and thread locking is managed on Solaris, causing the write ()
thread to be starved so it can only occasionally be called, every 4 seconds or
so?

This would explain why increasing the SunAudio write buffer to 512K fixes the
problem, so that GStreamer can fill the buffer enough so it can continue 
playing while GStreamer waits 4 seconds for the next write call?


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