GNOME Bugzilla – Bug 325191
problem with auparse or mulawdec, choppy esd playback
Last modified: 2006-03-23 23:27:09 UTC
When I play the attached au file that uses mu format, I get this error. (gst-launch-0.10:12997): GStreamer-CRITICAL **: file gstobject.c: line 389: assertion `GST_IS_OBJECT (object)' failed I get this error with the following pipeline: gst-launch filesrc location=./crash.au ! auparse ! mulawdec ! esdsink Also same error using sunaudiosink instead of esdsink. It also seems to truncate the playback of the file
Created attachment 56495 [details] file that generates the error message
Created attachment 56496 [details] this file just seems to hang and gst-launch does not exit I also notice a problem with this file spacemusic.au. It plays the file, but then gst-launch seems to hang when it is done playing and never returns to the command prompt after running gst-launch.
Note the first attachment is called crash.au and the second is spacemusic.au.
The warning is fixed in CVS: 2005-12-29 Tim-Philipp Müller <tim at centricular dot net> * gst/auparse/gstauparse.c: (gst_au_parse_dispose): Can't use gst_object_unref() on a GstAdapter (#325191). I can't reproduce the hang when it's done playing. It seems to EOS fine here with alsasink, osssink and esdsink. What are the last few lines of output of gst-launch when it hangs? (ie. does it get an EOS message and go back to PAUSED/READY/NULL and hang in the process of shutting down, or does it never get to see the EOS message in the first place?) Another issue: playback with esdsink is choppy for me. Probably would help if either auparse or mulawdec set timestamps/offsets on buffers ...
It is working better for me now, spacemusic is not hanging anymore. Not sure what changed. I also notice that the output is choppy with esdsink.
interesting, two new segments arrive in the sink, one bytes, another in default format. The first one is closed by the second one. no timestamps/duration on the buffers so an audiosink would do a best effort render. I'm amazed the result is that sucky.. investigating
esd is just very sucky with 8000 Hz apparently.
the esd plugin is not dealing correcly with the base class, it does not specify the buffer size it will used etc.
* ext/esd/esdsink.c: (gst_esdsink_class_init), (gst_esdsink_getcaps), (gst_esdsink_open), (gst_esdsink_close), (gst_esdsink_prepare), (gst_esdsink_unprepare), (gst_esdsink_delay), (gst_esdsink_reset): * ext/esd/esdsink.h: Fix esd choppy playback by configuring audiosink correctly. Fixes #325191
Wim, thanks for checking this out. I also had problems with the sunaudiosink having similar problems with choppyness - which might make sense because I based the sunaudiosink on the esdsink plugin. I hacked around this problem by hacking the "buffer-time" in the plugin to a big value (5000000), but this is probably not the ideal solution (since it causes annoying delays when you pause, change volume, etc.). Would you mind taking a look at the sunaudiosink plugin and seeing if it has the same problem? Perhaps we could remove the buffer-time hack if it does.