worked flawlessly!

I just decided to give the Linux client a go on my brand shiny new laptop. Here're the spec:

Intel core 2 duo 2ghz
nvidia geforce go 7600 w/256mb
1gb ram
Gentoo using the latest stable nvidia driver
kernel 2.6.20.6
X.org 7.1.1
1280x800 display (8:5)

(it's one of these: sager NP2030C)

This is one heck of a nice little laptop, and it runs SL at 20-35fps in windows.

In linux, the thing gets an average of 70fps in the same spots.

It's one thing that there's a linux client... it's an entirely different thing that it actually worked without any coaxing and WAY outperformed the Windows client. I mean, it's not that I don't believe that Linux is a superior operating system... but honestly, when it comes to things like games and media, I expect things to still feel a bit rusty around the edges. This totally didn't... the nvidia drivers for Linux seem to be rather robust.

Better yet, no configuration was needed. I don't mind getting my hands dirty, but it's a bonus when I don't have to! All of the OpenGL X stuff seemed to work out of the box, and SL ran flawlessly when I started it up. I disabled LL_GL_BASICEXT, and all features of the client worked perfectly (except, of course, video).

One little thing... I've got sound set up using ALSA, and the client finds that just fine, but there seems to be a half-second buffering delay in there somewhere. Has anyone got any advice on how to fix that before I start digging?

Annoyance 1: SL doesn't seem to handle my (somewhat irregular) resolution well in full-screen. I set the aspect ratio to 8:5, and everything looks good and undistorted, but the pie menu is an oval.

Annoyance 2: I use synergy, with the laptop as a client. When I try to alt-zoom on anything in windowed mode, the zoom goes out to full distance. I think synergyc does some things that SL doesn't expect with regard to the mouse. Alt-zooming works fine with the built-in touchpad in windowed mode. Fullscreen works fine with synergy.

Annoyance 3: When I have SL in full-screen mode and move my mouse pointer off to another display using synergy, the SL client seems to sort of flip into windowed mode. It gets window manager decorations and scoots so that they're visible on the screen. Not a huge problem.

Hey, just wanted to chime in that I'm also having the issue with Synergy messing up my alt-zooming on linux (Ubuntu 7.04).

Sweet! I think we have a bonafide bug.

I started playing SL again after about a year in linux, a few days ago I was booted into windows to make sure a project compiled and I figured I would give the windows client a shot and... man is it slower then the linux version....

In windows their is a noticeable delay between when you lift the key and your avatar stops moving. It was so bad I developed a headache untill I booted back into linux (Windows could be the cause of the headache tho )

From what Ive spoken to people this delay seems common... Damn I would die if it happened to me every day...

For the most part I would say the linux client is on par if not better then the other clients. I still the the occasional hangup, but it takes all of a few milliseconds to kill the window and start up again.

The sound delay is in the windows client also. I think it is grid lag or packet loss. All the problems I've had have been since January when they split the server locations.

No, I'm nto talking about the sound lag due to downloading sounds... I'm talking about a noticeable delay between right-clicking something and hearing that "bink" sound. The windows client doesn't exhibit this delay.

Annoyance #2 SOLVED! There's an option in synergy called "relative mouse moves". You turn it on in the server, and then whenever you move to a client and hit scroll-lock to lock your mouse to that screen, the synergy client stats using relative mouse moves instead of absolute mouse moves. For me, this handily fixed the problem of using the SL client in windowed mode with a linux synergy client.

This pretty much negates Annoyance #3 for my purposes, too, since I don't need to go into fullscreen to solve annoyance #2.

As to #1, I found out that even though the client logged about using ALSA, it was still running ESD. I have yet to figure out how to make sure it uses ALSA... I just haven't had time to futz with it.

hmm, I have it also, I almost always remember it being that way...

So, when the client uses ESD, I get a half-second latency on all sounds. When the client uses OSS (ALSA's OSS emulation), I get horrible stuttering. When the client uses ALSA, it claims it initializes fine, but I get no sound at all (I've checked muting and whatnot).

The last seems odd to me... it oughta work. Maybe SL is using old alsa libraries? I can't tell, because it's statically linked, and the lib/ directory doesn't have any alsa libraries in it.



Thoughts, anyone?

I found a replacement for the (crappy, in my opinion) ESD, PulseAudio. It has an ESD compatibility mode, so I hooked that up. SL uses it fine, and I still get the exact same delay. PulseAudio claims to be much better about things like latency, and it also claims to be good at MEASURING latency. It seems to think the latency for my sound card is 50ms, but that the latency for the fmod client (SL) connected to it is 242ms. That makes me think that SL's to blame as far as the latency goes.

I tried other various ways of getting SL to connect to pulseaudio, in hopes that I could bypass its ESD support. The padsp OSS -> pulseaudio wrapper died with a failed assertion. Using esddsp so that it went OSS -> esd emulation -> pulseaudio didn't help the buffer situation at all (big shock). I couldn't get the pulseaudio ALSA _input_ plugin to work (it's a plugin that routes alsa clients through a pulseaudio server) either. And finally, just going straight alsa, as I said before, doesn't seem to produce any output, even though it seems to initialize well.

So, I think there are two SL Linux sound bugs:

1. ALSA output doesn't work.
2. ESD output is buffered at least a quarter second, leading to latency.

Has anyone else gotten ALSA support working?

hmm you can tru it with the alsa oss wrapper (aoss) but sound seems to stutter, but the delay seems to be gone.. Also get lots of nifty "FSOUND_Output_OSS_Wait : Timeout on audio write. Caused by bad driver!"..

try enabling oss and run $ aoss /path/to/secondlife

Straight up OSS works great. Probably something with my sound configuration..

oh well ESD works fine for me atm so I will be sticking with it. The only thing really noticeable is the radial menu..

FMOD is the third-party library which talks to ESD and ALSA, so this is where the breakage appears to lay. For those who like details, I believe it tries to load libasound dynamically; I suspect it's getting different symbol versions on some systems than it expects (libasound uses symbol versioning heavily rather than API renaming).

It's on my TODO list to coax some recent source out of the FMOD developers and fix some of these problems, but it's not a high priority in the short-term.

Tofu, that makes sense... although sound does seem to load just fine. I guess that could be explained by FMOD finding the symbols it needs but not calling the functions properly.

Aoss resulted in the same error message that Kerik got (a few per second), and, oddly enough, less stuttering than straight alsa OSS backward compatibility. Still lots of stuttering, but no delay.

I tried running in OSS mode without AOSS and with nice levels of -5 and -15... no help.

Tofu, let me know if there's anything else you want me to try.

Funny thing was straight up alsa-oss worked fine in my system. it was aoss that seemed to give issues.

If we could get aoss to work then that would be a semi decent mode to use untill alsa works :\