Today, the question came up, how to use Second Life Voice under Linux. Here’s how:

First, you need a separate sound card for Voice, that doesn’t get occupied by other resources. Commonly, that would be a Headset with a USB plug (I use a Logitech Premium Notebook Headset, I think it’s worth the price, but with the right alsa config any piece should work).

Second, you have to configure your Alsa to use dmix and dsnoop on the in- and outputs of both Audio devices. (Save your old ~/.asoundrc and /etc/asound.conf if all else fails.)

Here’s my /etc/asound.conf:

# both hardware cards get a symbolic name instead of the
# hw0 and hw1. Find your
# card names with cat /proc/asound/cards

pcm.logitech {
type hw
card Headset
}
pcm.edirol {
type hw
card UA25
}

# now the logitech headset output is plugged thru dmix

pcm.lomix {
type dmix
ipc_key 1344
slave.pcm “logitech”
}

# and the input through dsnoop

pcm.losnoop {
type dsnoop
ipc_key 1343
slave.pcm “logitech”
}
#same for my edirol UA25

pcm.edmix {
type dmix
ipc_key 1346
slave.pcm “edirol”
}

pcm.edsnoop {
type dsnoop
ipc_key 1345
slave.pcm “edirol”
}

# input and output are plugged together again with the asym module

pcm.asymed {
type asym
playback.pcm “edmix”
capture.pcm “edsnoop”
}

# and get a plug abstraction
pcm.pasymed {
type plug
slave.pcm “asymed”
}

# and a mixer button (this card has no programmable mixer,
# just lots of knobs^^)
# You won’t need that with a builtin card, just plug the
# default (next unit) directly into “pasymed” instead of “softvol”.

pcm.softvol {
type            softvol
slave {
pcm         “pasymed”
}

# now it gets defined as the default in/output

pcm.!default {
type             plug

slave.pcm       “softvol”
control {
name        “SoftMaster”
card        UA25
}

}
# same for the logitech headset
pcm.asymlo {
type asym
playback.pcm “lomix”
capture.pcm “losnoop”
}

# this needs no mixer and no default! so we’re done
pcm.headset {
type plug
slave.pcm “asymlo”
}

As you can see, right at the beginning I’m defining symbolic names for both of my cards, so I don’t have to mess with the hardware numbers later (the numbers get messed up anyway, when you plug off any of the devices). Then, I define a dmix sink and a dsnoop source for each device, and plug them together with a asym type. One of the resulting pcm devices gets my default. (I also define a soft mixer for my UA 25 sound device, since this has no builtin mixer. It depends on your Soundcard, if you need that.)

To test this setup, close all audio software (Flash are notorious for blocking audio, so close your browser. And Skype, oh my.) . Stop all your Sound daemons, like esound, pulseaudio and so on. Restart the alsa service for your machine. Now: you want all sound sinks to play serveral sources simultaneously:

aplay -D default somelong.wav & sleep 1 ;  aplay -D default somelong.wav # this line is not broken by definition

This should result in playing the same file with a 1 second “echo”, and NOT in any error.

Now the same for the not-default headset device:

aplay -D headset somelong.wav & sleep 1 ;  aplay -D headset somelong.wav # this line is not broken by definition

This must also play the chosen wav file 2 times, the second one delayed by one second. As long as you don’t get that running, you can check with alsamixer -c 0 and alsamicer -c 1, if both cards are running, and with cat /proc/asound/pcm  or aplay -l if your pcm devices are up.

Next comes the tricky part. It seems that the Vivox client wants a sampling rate of 32kHz for recording from your mic. Test it with:

arecord -D headset -f S16_LE -c 1 -r 32k  -B 2000 | aplay -D headset # this line is not broken by definition

This should record a signed 16bit Litle Endian 32000Hz stream from your Headset mic, delay it by 2 seconds and send back to the headset output. If that doesn’t work, call 0800-TORRID.
(If you have a nice job in the Virtual Worlds environment, call me too.)

OK. We now have a unoccupied headset device that can play (and theoretically record multiple streams at once, and record with the udocumented, but needed sample rate, Vivox seems to use. And we have a default device bind them all, err, I mean handle the rest, your Music, Flash, annoying keystroke  sounds… You get it.

Al we need now is a ~/.alsoftrc file to tell Vivox, which libopenal devices to use:

format = AL_FORMAT_STEREO16
cf_level = 0
frequency = 44100
refresh = 8192
sources = 256
stereodup =
drivers =

[alsa]
device = headset
periods = 0
capture = headset
mmap = true

This file (delete the ~/.openalrc stuff, and don’t use the old lisp notation, both is obsolete) tells the openAL which source to offer as default device. This is the one single point where you tell any lib to use your headset.

Important: Never use something else than the “Default” devices from the list that spring up in the Second Life Client, otherwise everything was futile. This means: DON’T USE esound, DON’T USE pulseaudio. Tell your ./secondlife script to use alsa only.

NB: Pulseaudio is a great software for Linux, it solves all sort of problems, but to do so, it captures all your audio devices, right at the hardware, which is exactly what we DOH NOT WANT. (For SL Voice, that is…) Tell your Gnome, Gstreamer, KDE, whatever to use your Alsa Default Device as source and sink, it works.

Oh, and I forgot someting important: Right now, with the current SL Beta client, you still have to patch the libvivoxsdk.so as described in the Jira:

Just go to your SL Client installation, in the lib directory, and run this little shell script:

#! /bin/sh
sed ’s/:$/: /g’ /proc/cpuinfo > cpuinfo
cp libvivoxsdk.so libvivoxsdk.so.bak
sed ’s/\/proc\/cpuinfo/lib\/cpuinfo\c@\c@/g’ libvivoxsdk.so.bak
>libvivoxsdk.so

# this script has4 lines. If you don’t know what you’re doing,
# buy a Mac.

Somehow the libvivoxsdk cannot parse /proc/cpuinfo right, under certain cirumstances. This script creates a cpuinfo file in your lib, and patches the library to use it, instead of the original.

Now you have Voice with Linux SL. I hope.

You can tweet this article (that's what I would do^^). You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.