No streaming audio (music) with 1.22.11 viewer

Last night I downloaded the new viewer (1.22.11); works great, except no streaming audio (music). All other audio (environment, gui sounds) works fine. Just no streaming audio.

Anyone else notice this problem?

I'm running Ubuntu 8.04; can't think of other pertinent details off the top of my head (at work now, not in front of machine). Streaming audio was working fine with the previous version of the viewer.

Thanks for any tips.

I'm having the same problem on Debian Lenny. It worked fine, now nothing.

Same problem with OpenSuSE. This sometimes happens with me after a crash, so I'll try a reboot.

[update]

I've swapped back and forth between the previous version and the new one. I can't hear music with the new version. It's not a problem if I revert. So I'm reverting until the next fix.

What was the last viewer version to work for you all?

Are you all using 64-bit versions of your distro?

Have you tried disabling OpenAL and forcing fmod usage in your secondlife file?

The version immediately preceding worked fine. 1.21.6.

I'm 32 bit Ubuntu 8.04. Haven't tried what you suggested. How does one disable OpenAL?

The same here. I have no sound with opensuse 32-bit and the new client.

The solution is to edit the secondlife file and find the part where it describes the use of OpenAL and uncomment the line that prevents OpenAL being used.

Thus you end up with

## - Avoids using any OpenAL audio driver.
export LL_BAD_OPENAL_DRIVER=x
## - Avoids using any FMOD audio driver.
#export LL_BAD_FMOD_DRIVER

I just did this and it works.

Thank you so much, it works! )

Just to clarify: which file is the secondlife file? the executable file that is just called "secondlife?"

thanks

errrrm, how to open it to edit it??

The file simply called "secondlife" is not a binary executable. It is a script that sets a number of environment variables and then calls the /bin/do-not-directly-run-secondlife-bin binary executable. To edit "secondlife", simply open it in your text editor. You can either open it from within your text editor, or right-click and choose "Open with text editor" (or "open with other application", then choose your text editor).

Edit to add: If you are not able to hear audio using OpenAL on a 32-bit distro, it is probably due to a GStreamer problem - either it is missing, incorrectly configured, or has missing codecs.

You can test your GStreamer configuration (to at least make sure it works) by running gstreamer-properties from a terminal window. If it works, and all of its sinks and sources are set correctly, then it may be down to missing codecs. typing:should fix you up (package names may depend on your distro. These are the package names found in the Ubuntu repository). Additionally, if you are using Ubuntu, adding ubuntu-restricted-extras to the apt-get list should help as well.

This fixes my problem. Thanks.

With enabling this option streams are working again here also, but are stuttery now, what hasn't been with the previous versions. Someone experienced this also?

Of course, not all distros have al the plugins available. This is a problem I have.

Why this is, I do not know, but i suppose this is the downside of not using an operating system which tells you what you can and can't do.

very surprising because gstreamer does not use openal at all.
That disabeling openal helps getting streaming audio to work points only to one thing:
You do not have a proper configuration file for openal. Then openal might use /dev/dsp by default and block all other audio (except you have ossV4 installed).
The proper solution most likely will be not to disable openal, but to have either a .alsoftrc in your home folder or a /etc/openal/alsoft.conf - forum search will find one or more good examples.

No, you're right, it doesn't. Nor does OpenAL use gstreamer - but it may depend on gstreamer for codec support, maybe.

I actually have no real idea how OpenAL works. However, I have noticed, thanks to Pulseaudio's paman, that 3-4 sinks are created when SL is running.

The first sink is the SL environmental audio and script/gesture sounds.
The second sink is SLVoice.
The third and fourth sinks are streaming audio and media.

If fmod is used, then only two sinks are created - one for all SL audio including the streams, the other is SLVoice

I believe that, rather than using OpenAL, SL might be using gstreamer directly for its music and media streams. This may be why some people can hear SL audio but not hear streams, if gstreamer is either misconfigured or missing.

Next time I have SL running, I need to look into exactly what is creating the streaming music/media sinks; however, I suspect it's either using MPlayer, or the viewer has MPlayer functionality built in. So, here's a suggestion for those not able to play streams in SL: Make sure you have MPlayer installed and working. It's a long shot, but it might be the reason.

thats actually the way it is.


no, SL is not using MPlayer nor has MPlayer functionality built in. Well, installing MPlayer is anyway a good suggestion ...
For gstreamer the ffmpeg plugin is what gets most streams working (check first if ffmpeg is legal where you live). Could be that ffmpeg and relating plugins are installed as a dependency of mplayer - or not, I don't know.

For getting gstreamer working with pulseaudio there is a plugin (libgstpulse.so), too, if gstreamer shows up in the padevchooser then it's already installed. The gstreamer website says its part of the "good" plugins, for unknown reason debian squeeze packages it separately as "gstreamer0.10-pulseaudio" .

At any rate, it's a good way to confirm one's gstreamer installation is working.ffmpeg is a separate package that is neither installed with the distro itself (for obvious reasons) nor is a dependency for MPlayer. This may be where a lot of people who have never been able to stream music from SL may be running into issues. It *may* be installed as part of the Ugly package, but not sure.Ubuntu packages it separately as well. Not sure if it's just a Debian/Ubuntu (and Ubuntu derivitives) thing, or if it is that way for the entire Debian tree. Gstreamer *should* work with Pulseaudio with its ALSA plugins, but why force emulation when one can do it natively?

I don't think MPlayer uses GStreamer. Totem does, though. But in my opinion, GStreamer easiest to test with
gst-launch-0.10 playbin uri=http://example.com/mystream # replace the URI by an actual media stream's address, e.g. from SL's 'About Land' window

Right you are. Apparently MPlayer has its own engines

*sigh*

Just when I thought I finally had Linux' audio alphabet soup figured out.... At least I'm not using KDE - I think my brain would explode!

In line with everything said above, OpenAL isn't the problem -- audio in Linux clients (eg. ambient and UI sound) works fine in both 32-bit and 64-bit systems. It's only when gstreamer gets invoked for land audio and land video that things go awry.

The latest official 1.22.11 client shows this well.

With OpenAL enabled (which is the default), both 32-bit and 64-bit machines have ambient and UI audio working just fine, so OpenAL works in both. On a 32-bit Linux system, land audio and video streaming both work too, and miraculously, so does voice (but not in every voice-enabled zone, not sure why).

In contrast, on a 64-bit Linux, 1.22.11 crashes instantly as soon as land audio is enabled, claiming the usual nonsense about a distro's 32-bit emulation libraries needing to be installed. It's "nonsense" because you can install every known 32-bit emulation library under the sun and you still get the crash --- this is entirely independent of which distro you are using (all the main distros track each other on 32-bit emul libs). The matter is made worse by the unhelpful crash handler not actually specifying which library failed to load.

Likewise for video, there is an immediate crash on 64-bit Linux as soon as the land video button is pressed, with the same error mesage. Again there is no indication of which shared library gave rise to the fault, and the stack trace doesn't give any useful information either (do_elfio_glibc_backtrace / LLAppViewer::handleSyncViewerCrash / LLApp:etError / default_unix_signal_handler).

When OpenAL is disabled, the resulting behaviour on 64-bit Linux supports the above conclusions: land audio streaming now works (because FMOD stream handling doesn't use gstreamer), and land video streaming still crashes in the same way as before (because gstreamer is still required). So it all comes down to gstreamer woes on 64-bit.

Oddly enough, this whole issue could be resolved with just a day or so's work: LL should just build a native 64-bit version of the client so that 32/64-bit emulation problems become irrelevant. The sources already compile fine on 64-bit Linux as they stand (many people have done it themselves), so all that's required is to package up the pre-built libraries as is done for the 32-bit release.

Tofu's answer in the past has been "Well let's get the 32-bit client working first", but this is completely the wrong approach as it misses the point that 32 and 64-bit clients are identical, and that releasing the 64-bit build need take no extra development time once the new build workflow is set up.

The fact that 64-bit Linux users are treated as second-class citizens while waiting for some unknown future date when everything works on 32-bit is a shame, and is unnecessary. (And you're missing the feedback that the 64-bit community would provide too.)

Relying on 32-bit emulation is simply the wrong way to go, given that the barrier to a native 64-bit release is somewhere from little to nil.

Morgaine.

I don't think that's been my response. The fact is that we're not going to issue official releases that we don't do complete QA on, and doubling the QA for Linux (32-bit and 64-bit releases) isn't going to happen in the foreseeable future; enjoy the unofficial 64-bit builds lovingly created and QA'd by third-parties you trust which are possible due to our open-source license. I can (and reckon I have) expand on the details of this in more appropriate threads.