[gstreamer-bugs] [Bug 345679] fix to avoid goom core dumping

[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=345679
 GStreamer | gst-plugins-good | Ver: HEAD CVS





------- Comment #4 from Brian Cameron  2006-06-23 17:51 UTC -------

Thanks Wim - your patch works great - just tested it.  Goom no longer core 
dumps.  Probably a good thing to initialize the memory, so I hope this goes
into 
the codebase.

Although, I should say that goom isn't really functional on Solaris even with 
this patch.  It seems that there are some serious performance issues.  With
goom 
turned on, it seems to cause the audio to stutter as if the CPU is being 
overloaded.  

As you might remember, the sunaudiosink hardcodes spec->segsize to 4096 and 
spec->segtotal to 128 in the prepare function, so we are using a fairly high 
buffer size.  This was needed because with smaller buffer sizes, I was noticing
that a similar stuttering problem was causing audio playback problems.  
Unfortunately, setting the buffer so large causes a number of performance 
issues (such as a several second lag when changing volume in programs like 
totem/rhythmbox and makes some buttons less responsive such as fast-forward 
and rewind or trying to scroll to a different time in the song).

I notice that when goom is enabled the large buffer also seems to cause totem 
to pause for several seconds before playing the audio file, which makes it 
look like totem isn't doing anything.  Also annoying.  I did try setting the
sunaudiosink buffer to a larger size to see if it would fix the stuttering
problem with goom, but this didn't seem to help.

To be honest, I'm not really sure how to attack this problem.  Perhaps
GStreamer 
needs some work to be performant on Solaris (since I notice, for example, Real 
doesn't seem to have these sort of problems - and we didn't have these problems 
with GStreamer 0.8).  

Perhaps thread priorities or something should be used to ensure that the
goom plugin doesn't suck up so much processor time?  I ran totem with goom
playing an ogg file and I notice that 6.815% of user CPU time is spent in
zoomFilterFastRGB and 4.933% in getPixelRGB_, both goom functions.

I believe that Sun provided Fluendo with a few Sun machines so that you could 
provide the Fluendo plugins on the Solaris platform.  I don't suppose you could 
take a look at this and see if you can identify why GStreamer performance seems 
to have these issues?  If you would, that would be great.  Thanks.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.