|
|
|
[
Permlink
| « Hide
]
Iskar Ariantho added a comment - 03/Feb/09 05:16 AM - edited
Same things now happens with the branch/viewer-1.22, svn 109348 version. (obviously, as it seem to have gotten merged from the other branch, picking up the same issue.)
Can you please provide us with reproducible steps and an example stream URL?
Its easy. go to ANY land with a stream active and press play. You will be greeted with silence. Example stream: 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... Oh, while browsing idly on the internet, i found out its possible to set GST_DEBUG to have gstreamer be a bit more verbose over its internal workings.... This is the snipped from the screen that might be of interest:
===================== 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. Ok, got it nailed. The attached patch fixes the issue. It turned out there is a race condition where gst_init_check forks and waitpids on the result, but the in llcommon/llapp.cpp installed signal handler picks off the result first.
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... That's some interesting debugging, thanks. So how about if the viewer just stops catching SIGCHLDs? I'm pretty sure it doesn't need to (the fact that it does is a holdover from the shared code with servers).
So, this 'foo.patch' would be good to test!
Tested it, and it does NOT work. (bleah, a total recompile just to suppress the setting of SIGCHLD, whatever happened to a simple //
 )
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 Huh, so much for the GStreamer docs - again.
If there's a chance that other libs are dicking with SIGCHLD, which there is, then I want to leave the LL_IGNORE_SIGCHLD stuff intact. I'm concocting a mix of our patches. I hope you can try it.
 There, how's foo2.patch for you?
if you want to enclose the signal stuff in LL_LINUX, i think you should place the struct sigaction tmpact, oldact and the restore of the old sighandler also under LL_LINUX
New version is compiling.... Good point, I started the LL_LINUX bracketing and got distracted by one of those 200 other things going on.
Yup, the latest patch works ok for me. Be amazed, be happy
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! Hooray, thanks for the debugging, patch and testing.
I'll get this on maint-viewer and the RC release team may or may not cherrypick it to 1.22; if not 1.22, 1.23. from OpenAL wiki:
"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 1.22.9 now work on linux for audio stream, both mp3, ogg, fixed or variable rate
OpenAL 1.4.272 @Tayra Dagostino, please note the the openal support in 1.22.8 requires openalsoft. The openal wiki refers to the old and outdated openal from creative labs. I use .alsoftrc with the following
[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 Hello,
this is my first time to post a comment here. I'm facing the same problem ... I don't have music inworld with this latest viewer. Although I'd like to use above patch, I don't know how to use it. This question must sounds a beginner's, but could anyone tell me how to use it? Thanks. My problem was ONLY "music" not working (means that all sound but music was working in this new version).
I solved it uncommenting this in "secondlife" script loader: #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 upgrading to lenny solve problem, using directly openal
Using 1.22.11 on Ubuntu 9.04, streaming was not working. Commenting out the LL_BAD_OPENAL_DRIVER so it used FMOD fixed it. But you can not have any other programs running that use audio, such as RhythmBox.
However, RC 1.23.2 broke it again and the workaround does not fix it any more. Fixed in 1.23.4, released on 06/15/2009.
I don't know if this is the right place for reporting this, but :
On Linux 64 bit and SL client 1.23.4 (123908).
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Normal
SVN-108641 Linux stopped playing streams
