Finally published my own pfText.

Adam Frisby, co-creator of OpenSim announced earlier this day on the Opensim-dev mailing list that he added a new transport protocol to the OpenSim server, MXP or Metaverse Exchange Protocol is being worked on.

“MXP concentrates on messages required for the defined 3d simulation model. MXP specification does not contain application specific concepts but acts as a transport layer for specialized interaction and state data described in Metaverse eXchange Markup Language (MXML).”

He also announced to have several Virtual Worlds Environments checked for “Openness” of the protocol and possible interoperability:

• ActiveWorlds: No protocol documentation, and the company running it is likely to get snippy and involve lawyers (of course if they say otherwise, I’d be happy to look into adding compatibility).
• There.com: Ditto, no protocol documentation.
• Forterra: No protocol docs, described us as “Communists” at a UK Serious Games Conf panel. Probably not a great choice.
• Croquet: No adapter being worked on (I was working on VastPark – which we started today and will finish tomorrow/weds.). Would be interesting to try however – would definitely need help from the Croquet team.
• Wonderland: A option if we can get past licensing issues (it’s all GPL). If their protocol docs are nicely licensed we could build a library from that for .NET. If they make a concession on their protocol libraries to LGPL, then we could IKVM them.

Here’s Adam’s blog post about both the collaboration with VastPark and the new protocol implementation; an article on Virtual Worlds News is here.

P.S.: Congratulations to @Prokofy on her new job at Forterra!

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.

I’ve described the new URL scheme for Second Life and Opensim Grids and places in a previous article. Now with the latest update from subversion, the normal

python setup.py build ; su -c “python setup.py install”

is working under linux. Also I found how to run the URL handler directly from Firefox 3.0.5:

On my system, it is not sufficient, to simply define the protocol handlers in the about:config of Firefox.

network.protocol-handler.app.rezzme     (string) /usr/bin/rezzme.py
network.protocol-handler.app.rezzmes   (string) /usr/bin/rezzme.py

In addition to that, I had to define 2 boolean values, like:

network.protocol-handler.external.rezzme   (boolean) true
network.protocol-handler.external.rezzmes  (boolean) true

After that, the test URLs open fine by clicking. Please note, that the Urls need quite some time to open, while it works very fast from the commandline. Dunno why yet…

Update: The bad delay appears only when trying the example.net-link. Just ignore that^^

I found a nice new project yeasterday: The rezzme:// URI scheme is a method to bookmark virtual places that goes far deeper than the secondlife:// or SLurl system, which both are limited to Second Life.

Usage (examples):

• rezzme://example.net:9000/ (Log into a certain Simulator)

• rezzme://Torrid%20Luna@primforge.org:9009/ (" with a certain Avatar name)
• rezzme://opensim.zurich.ibm.com:9000/zurela/128/34/23 (Go to a special place within this Grid)

Of course, just defining a new URL scheme does nothing yet,  you need a program that understands the URL scheme.  Under http://forge.opensimulator.org/gf/project/rezzme/scmsvn/?action=AccessInfo there’s a protocol handler, written in Python/Qt4, that is able to parse the rezzme-Scheme and bookmark the URLs. It even enables you to define several different clients to open certain adresses with, so if you want to use the Meerkat or Hippo viewer for a certain address, this is no problem.

The handler is available for Win and Linux so far, a Mac version should follow soon. It simply saves the bookmarks and defined clients in 2 files in your home directory, .rezzme.clients and .rezzme.bookmarks. By adding the rezzmy.py program to your Firefox config you will be able to start these clients by simply clicking a Web URL.

Way cool.

</p> <p>Ihr Browser kann leider keine eingebetteten Frames anzeigen:<br /> Sie k&ouml;nnen die eingebettete Seite &uuml;ber den folgenden Verweis<br /> aufrufen: <a href=”/pano-sl/” mce_href=”/pano-sl/”>Panorama SL</a></p> <p>

Panorama made with Hugin from 8 SL Screenshots,

Javascript renders one 2000×300 image into a 360 degree scrolling view

Crossing borders between different Virtual Worlds is the next big thing. (I tell ya!^^) While there will probably never be an archetyp Avatar, that bears all possible features of any imaginable VW, taking your N identity into the M world is increasingly important.

In their Blog, Linden Lab announced one more kludge to make that happen: Now with every Slurl you create, there comes a button to create an avatar on the fly, if you don’t have one yet. So, the route from any medium with http links (Websites or a Skype chat as in Torley’s example video) to Second Life is a known passage now.

While I seemed to be one of the first (mortal) users to have Second Lifeŧ Voice running on Linux, I usually don’t use it, and with the recent updates, it didn’t work anymore. Now here come 2 kludges to fix your Linux Voice with the current Clients:

1. Install a pulseaudio enabled libopenal. This may or may not be nessecary, depending on how recent your system is, it’s described here.
2. On systems that don’t have a power management enabled CPU, libvivox seems to bail out (Jira Entry). The fix is funny, you create your own “/proc/cpuinfo” in your secondlife-directory/lib, and change the lines starting with “power management:” to “power management: “. Note the gap.^^ Now you just “patch” the libvivox (with good old sed) to read from there, instead of the /proc interface.
3. Voila, I have a white dot over my head, and can see other people in the chatbox. Now I’ll run get some batteries for my Mic.

Cool findings, thanx to Peace Howlett and Xaden Kjeller!