Voice on Linux How-To?

Hi,

Is there a concise how-to for Linux users who want to use voice in SL?

I'd like to know about hardware selection / requirements (both sound hardware and microphone / headset) and software configuration.

(I'm aware of the thread "Voice Support for the Linux Client" / /263/74/206270/1.html but frankly I'm a bit too lazy to wade through its 200 replies to extract the information I need, assuming it's even there.)

I'm running SL 1.19.0.1 under openSUSE 10.3 on an ASUS P5B/Deluxe mainboard (no add-in sound hardware, just the on-board Intel 82801H HD audio controller, and an nVidia video card) with a Core 2 Duo CPU.

Thanx!

Rudy

I posted this in the voice support thread. If you ignore the stuff about Wine (now that the Linux blob is released in the rc and wl) the rest should make it work.

http://www.paganstead.com/extras/sl_voice_linux.txt

Post again if you have any questions.

Adamas

Thanks, Adamas. I'll give that a go.

Do you have any recommendations for what should I look for in buying a microphone / headset for SL voice chat??


Rudy

I'm just using a cheap Plantronics headset I bought a year ago for something else. I don't know enough to be able to recommend anything, but this seems to work pretty good.

Adamas

Here's my small guide to do it with a USB headset like a Logitech. I'll also have this in the Metaverse Messenger slated for next week. Thus, I quote:

I GOT IT WORKING!!! I'm using a Logitech USB based headset in addition to my regular audio. Here's what I did.

VIVOX USES OPENAL TO USE AUDIO. It's configuration is in ~/.openalrc. This is my configuration, using a USB headset as the second audio source:

(define devices '(alsa native esd null))
(define alsa-out-device "hw:1,0"
(define alsa-in-device "plughw:1,0"

Yes, they use Lisp.

Second, use ESD to direct all SL sounds (but not Voice) to your regular sound system. You may also use ALSA, whatever works for you. Run esd in the background.

Then run SL... and connect... with voice!

Okay. I gotta say this because distros seem to vary greatly. With OpenSUSE and probably other distros, ~/.openalrc does not exist. Putting one in there breaks voice. There is an /etc/openalrc (notice no dot) file, but messing with it messes up the audio system. This is what is in OpenSUSE's /etc/openalrc file by default:

(define devices '(alsa native))
;; uncomment this to output via the 2nd soundcard
;define alsa-device "plughw:2,0"

If you try to put in params other than this in this file it will not work.

If Vivox uses OpenAL for voice, it is getting forwarded to alsa by default. On these systems, you don't mess with OpenAL for voice services, you use ALSA, ESD and PulseAudio.

I understand Gentoo works a certain way, and playing with OpenAL makes stuff work, but those methods won't work with OpenSUSE and probably many other similar (and popular) distros.

Last, it might be helpful to know how to direct ESD or ALSA to do certain things, like use alternate audio inputs and outputs. I find (using one audio card, like most people) that using anything other than default settings for everything breaks voice and/or audio. Also, remember different distros put config files in different places. Just because Gentoo puts something like .openalrc in a user's home folder, doesn't mean anybody else does that.

Adamas

It does. It's what's bundled w/SL, and a library trace points to the libopenal.so that is included.

SL itself (since Vivox runs seperately and interfaced via TCP/IP) uses FMOD (previously discussed and there's many patches for moving it to OpenAL).



Not really. I don't have OpenAL installed system-wide on my Gentoo box -- I never had a need for it. So I'm using the OpenAL libs that SL provides... and if you checked the ./secondlife script, it loads any library SL provides first.



I doubt it's that we put it in different directories, it's more like there's two .openalrc's -- the system version on /etc/openalrc and a user version that overrides the system on ~/.openalrc. Both are read -- system first followed by user. That's standard M.O. on many programs and libraries, including ALSA itself (which is drivers for the hardware and libraries for interfacing with it).