FS#4333 - Totem sound output skips ridiculously when moving window

Attached to Project: Arch Linux
Opened by name withheld (Gullible Jones) - Saturday, 01 April 2006, 02:27 GMT
Last edited by arjan timmerman (blaasvis) - Saturday, 01 April 2006, 08:28 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Jan de Groot (JGC)
Architecture not specified
Severity High
Priority Normal
Reported Version 0.7.1 Noodle
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

If you use a libvisual display plugin for the GStreamer 0.10 build of Totem, then sound output will stop if you move the Totem window around for a few seconds. This state will last until a few seconds after the window stops moving, at which point play will skip ahead by an amount of time roughly equal to the time for which sound output was halted. This phenomenon produces no unusual console output. It is also completely unaffected by any changes of the nice and memlock values for audio in /etc/security/limits.conf.
This task depends upon

Closed by  Jan de Groot (JGC)
Monday, 03 April 2006, 06:13 GMT
Reason for closing:  Not a bug
Comment by Jan de Groot (JGC) - Saturday, 01 April 2006, 18:43 GMT
Somehow visualisation plugins in totem take quite some CPU load. When I play an MP3 on my system and put the default GOOM plugin to the highest size, sound is all choppy or just stops playing. When using the small or normal sized visualisation setting, everything is fine, whatever plugin I choose.

Edit: running a libvisual plugin in xmms with extreme things results in completely hanging X, while sound continues to play. Mouse will stop responding for 5 or 10 seconds now and then in this case.
Comment by name withheld (Gullible Jones) - Saturday, 01 April 2006, 23:21 GMT
Hmm, also happens when I resize the window.

I've been thinking, GStreamer 0.10 can output via SDL, Xv, or Xll without Xv... But not OpenGL, and Xine seems to use GL by default. Is there an OpenGL output plugin for GStreamer 0.10? Because I think that would solve this...

(Also, could someone tell me if these performance problems occur under XGL?)
Comment by name withheld (Gullible Jones) - Saturday, 01 April 2006, 23:29 GMT
Uhh sorry about the double-post, just discovered that it's not only a libvisual problem. That sucky Goom display is actually something that comes with GStreamer... I think this is a general video output problem. Now, there was a gst-plugins-opengl plugin for GST 0.8.x, which allowed output to "glsink", but I can't find the equivalent for version 0.10, and setting up custom video output with "glsink" doesn't seem to work...
Comment by Jan de Groot (JGC) - Sunday, 02 April 2006, 09:21 GMT
The opengl plugin is included in gstreamer0.10-bad nowadays, it's called glimagesink. I can't get it working on my system though, it can't initialize opengl somehow.
Comment by name withheld (Gullible Jones) - Sunday, 02 April 2006, 17:25 GMT
Ick, I guess that's why it's a "bad" plugin.

BTW, does GST 0.10 display similarly excessive CPU usage when playing videos?
Comment by Jan de Groot (JGC) - Sunday, 02 April 2006, 17:40 GMT
Not as far as I know, videos play fine now. GStreamer 0.10 still needs some work on codec support in some places, but overall it's a lot better than gst 0.8.
Comment by name withheld (Gullible Jones) - Monday, 03 April 2006, 00:59 GMT
Ebeh... still not as good as Xine, even if it's conceptually better. It would be nice if the GStreamer people would only release things once they worked, and nicer if the Gnome devs only based stable releases off of given software once said software worked. [/rant]

Loading...