"BAD_OSS" in startup script makes login hang

Looks like "BAD_OSS" in the startup script makes login hang with some newer viewer versions, at least on my machine.

http://jira.secondlife.com/browse/VWR-2490

Anyone else seeing this one? Took me quite some time to notice it's being caused by the "BAD_OSS" option, because I've been using "BAD_OSS" since ages to avoid SL locking other tasks out of the sound daemon.

If you're running KDE as a desktop you could try:

artsdsp -m esd -terminate -nobeeps &

Just before running SL.
It runs the esd (enlightened sound daemon) but routes it through KDE's sound system.
The -terminate bit tells it to quit when SL has finished running.
Then you can disable alsa and oss from the startup script.
Works a treat here!

I'm using gnome

If I remember correctly, I've tried ESD and ALSA wrappers before, but they all delayed sound playback from Second Life, which the startup script options didn't. The "BAD_OSS" option worked fine for me in SL 1.18.0.6 and earlier, so I guess something got broken that wasn't before.

Shrugs

It's an arts wrapper not an alsa wrapper and I don't seem to get any noticeable delay.

But I don't really get your problem. Using the BAD_OSS option should stop SL from looking for OSS. Am not sure how that manages to crash it?

Even if it doesn't find any audio it used to start up with no sound. Maybe that's changed?

I've never been able to use the "BAD_OSS" option from day one. I initially tried it because I wanted to be sure it used ALSA directly, since I tend to get better performance that way, rather than using ALSA's OSS emulation layer. However, when I enabled BAD_OSS to disable OSS detection, the viewer crashed/would not start (it's been too long and I forgot what exactly happened) so I just assumed it would not run under ALSA and left it alone. Either way it still runs under ALSA, only it appears to be using the built-in OSS emulation provided by ALSA.