http://scfire-dtc-aa01.stream.aol.com:80/stream/1003

BTW, i have traced the issue down to a failing call to gst_init_check(NULL,NULL,NULL) at llmediaimplgstreamer.cpp:196. No idea why it fails tho. As said, totem and even gst_launch have no issues.

I'm running on a pretty stock Centos 5.2 system, with gstreamer 0.10.9 (with an added gstreamer-ffmpeg-0.10.2 to be able to play mp3 streams)

Note. i was able to bypass the entire gstreamer issue by setting LL_BAD_OPENAL_DRIVER, making it fall back to the working fmod. This however does not constitute as a proper fix in my opinion. There still is an issue in the gstreamer setup sequence somewhere...

=====================
grab_gst_syms:81: Found DSO: libgstreamer-0.10.so.0
grab_gst_syms:40: Failed to grab symbol: gst_segtrap_set_enabled
grab_gst_syms:41: Failed to grab symbol: gst_message_parse_buffering
grab_gst_syms:42: Failed to grab symbol: gst_message_parse_info
grab_gst_syms:94: Found DSO: libgstaudio-0.10.so.0
grab_gst_syms:108: Found DSO: libgstvideo-0.10.so.0
startup:191: gst_segtrap_set_enabled() is not available; Automated crash-reporter may cease to function until next restart.
INFO (0xae593658 - 0:00:00.000165000) GST_INIT(10765) gst.c(510):init_pre: Initializing GStreamer Core Library version 0.10.9
INFO (0xae593658 - 0:00:00.000240000) GST_INIT(10765) gst.c(511):init_pre: Using library installed in /usr/lib
INFO (0xae593658 - 0:00:00.000329000) GST_INIT(10765) gstquery.c(101):_gst_query_initialize: init queries
INFO (0xae593658 - 0:00:00.001543000) GST_INIT(10765) gstmessage.c(72):_gst_message_initialize: init messages
INFO (0xae593658 - 0:00:00.002851000) GST_PLUGIN_LOADING(10765) gstplugin.c(182):_gst_plugin_register_static: loaded static plugin "staticelements"
INFO (0xae593658 - 0:00:00.096187000) GST_REGISTRY(10794) gstregistryxml.c(572):gst_registry_xml_read_cache: loaded /root/.gstreamer-0.10/registry.i686.xml in 0.083507 seconds
ERROR (0xae593658 - 0:00:00.108149000) GST_INIT(10765) gst.c(689):ensure_current_registry_forking: error during waitpid: No child processes
startup:198: GST init failed for unspecified reason.
=====================

It seems forking is somehow prohibited? Maybe gst_registry_fork_set_enabled() might help here, but by the looks of it, that isnt supported in my older 10.9 version of gstreamer. Yuck.

Fixed the issue by looking for a recent gst function gst_registry_fork_set_enabled() to disable forking, or if that function isnt available, muck with the SIGCHLD signal handler during the gst_init_check call.

(Please note, the codepath when gst_registry_fork_set_enabled is available is NOT tested due to lack of a gstreamer > 0.10.10. The other part i can vouch for )

frowns ok, just noticed the patch still contained a commented out return for when grab_symbols fails. I need that line, because otherwise the OPTIONAL missing symbols will still halt loading gstreamer. Think there is a seperate codeing issue in the LL_GST_SYM macro...

Actually, i am not sure why it doesnt work, judging from the sourcecode i would say it should give the same end result, but since it doesn't, i can only assume some library (curl?, libmoz?) cant leave the signals alone...

I also looked at some other places the viewer forks, like the llvoiceclient.cpp where it forks SLVoice and llwindow/llwindowsdl.cpp (exec_cmd) for starting external browsers... However neither function cares about the waitpid result, so, even if waitpid fails due to the SIGCHILD race, it works out ok in the end.

Seeing the viewer doesnt use gst_update_registry(), there is no further forking in gstreamer, hence i would say my patch is the least intrusive to fix this issue.

Oh, as an aside, 'err' in your patch is still NULL after returning from gst_init_check, resulting in an ever so slighty crash when dereferencing it. Was the first thing i did myself, before discovering GST_DEBUG

New version is compiling....

I added a little debug info, and it seems upon arrival in llmediaimplgstreamer the SIGCHLD handler is set to SIG_IGN. So yup, somebody is messing with it. Hope to see the patch soon in 1.22!

"On Linux OpenAL will by default use the OSS kernel sound device."

all soundcard too much new and wothout retro-compatibility suffer problem with openal, workaround is create a file in user home

~/.openalrc

with only 1 line:

(define devices '(alsa esd native))

in this way openAL try first ALSA device, so ESD, and last native (old Open Sound System)

in this way OpenAL work with audio stream

1.22.9 NB still broken

OpenAL 1.4.272
Gstreamer: 0.10.19

Now (starting with 1.22.8), the viewer crashes when I start playing streamed sounds.

Update: it seems to be unrelated problems, because the patch attached here is apparently of no help for VWR-11947.

 
[general]
format=AL_FORMAT_51CHN16

[alsa]
device=plug:dmixs51
# mmap=off

Note that device is only for alsa, under [general] from the docs,

 
drivers =  # Sets the backend driver list order, comma-seperated. Unknown
           # backends and duplicated names are ignored, and unlisted backends
           # won't be considered for use. An empty list means the default.
           # Default is:
           # alsa,oss,solaris,dsound,winmm,wave

Also note that openalsoft is now 1.6.372 http://kcat.strangesoft.net/openal.html

I solved it uncommenting this in "secondlife" script loader:

#export LL_BAD_OPENAL_DRIVER=x
export LL_BAD_OPENAL_DRIVER=x

I dont use openal, I use alsa on all my Debian and Ubuntu systems, even ESD and OSS goes throught ALSA for me.

Its all self-explained inside the file and in readme-linux.txt, with some other options to try if that dont work for you.

EDITED: I forgot to mention that I didnt use any patch, I have the raw new update viwer only asked by the older client to upgrade.

Thanks for this post, starting here I could find the files and all.

Good luck

However, RC 1.23.2 broke it again and the workaround does not fix it any more.

On Linux 64 bit and SL client 1.23.4 (123908).

• with openal : ambient noises ok, no streams
• with fmod : no sound at all

be it with gstreamer enabled or disabled, and individual fmod backends activated or not.

I know this is a different problem, which origin is 64 bit linux libraries not called by 32 bits SL client. However it would be nice to have that resolved too (ideally by having a real 64 bits SL client).

Also, my feeling was it would be nice to tell other 64 bits users about this problem if they search the jira for hints.