GNOME Bugzilla – Bug 340258
[esdsink] esd_get_server_info() fails
Last modified: 2012-02-28 20:33:12 UTC
Hi, current gstreamer 0.10.5 with gst-plugins-base 0.10.6, gst-plugins-ugly 0.10.3, gst-plugins-good 0.10.4 refuses to play some MP3s. This MP3 here refuses to play: http://www.penny-arcade.com/docs/Treachery%20In%201080i.mp3 jacob@lappy:~$ gst-launch-0.10 playbin uri="file:///home/jacob/Treachery In 1080i.mp3" Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /playbin0/preroll_audio_src0: Internal data flow error. Additional debug info: gstqueue.c(782): gst_queue_push_one (): /playbin0/preroll_audio_src0: streaming stopped, reason not-negotiated ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... FREEING pipeline ... A complete log with GST_DEBUG=3 is located here: http://librarian.launchpad.net/2422665/log Bye Forwarded Ubuntu Bug: https://launchpad.net/distros/ubuntu/+source/gst-plugins-ugly0.10/+bug/42247
I _think_ the problem is here: WARN (0x80509a0 - 0:00:01.527431000) esd(24872) esdsink.c(214):gst_esdsink_getcaps:<actual-sink> couldn't get server info! Is there an esd running, or is it supposed to fall over to alsa at this stage?
Created attachment 64754 [details] [review] query server info in open() method I think we should try to query the server info already in the open() method (I assume the sample rate doesn't change randomly while the connection is open). That way we can fail already in the NULL=>READY state change (and let autoaudiosink try other methods). Also, we should post a decent error messages on the bus if we fail here. Patch has seen moderate testing only.
So let's reassign this to plugins-good for now
Any way you can test tim's patch? Is there anything special about the esd that you're running that makes it fail like this?
Maybe I should've noted that I only forwared this bugreport... I'll get a testpackage with this patch ready for the original reporter later today (or tomorrow, depending on your timezone)
This patch doesn't fix it... same behaviour as before
I didn't expect the patch to fix this, the patch just makes it fail earlier and with a better error message. Looks more like an esd/libesd issue to me though, we just open the connection to the server and then do esd_get_server_info(), I don't think there's too much we can do wrong here, unless this is expected to fail some times (which I find hard to believe).
I've asked Christian to bring in his Audigy 2 NX USB device so we can try and reproduce it here.
Have you ever had a chance to try this? Don't think this is a GStreamer issue, and the libesd code is pretty straight-forward as well (minus it not checking how many bytes are actually written to the fd), so it seems more likely to be some kind of esd server issue to me.
I don't really see how this could possibly be a GStreamer issue, moving to esd.
What exactly is the problem you are seeing from esd?
> What exactly is the problem you are seeing from esd? ctrl_fd = esd_open_sound (esdsink->host); returns a valid file descriptor, but then info = esd_get_server_info (ctrl_fd) returns NULL. That seems to indicate a problem on the esd side to me. Is there any additional error querying we should be doing on the GStreamer side to print out useful additional information?
This behavior makes very little sense when reading the code. And I can't reproduce it here.
"esound" has not seen code changes for more than three years according to http://git.gnome.org/browse/esound/log/ , and it will not see further active development anymore according to its developers. Closing this report as WONTFIX - Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.