I have orbited countless stupid noobs in SL.

But I have never
killed a noob in RL.
Not because there
are no stupid people.

There are no guns.
Not in my life.

Here’s the link to the flickr group.

(of course I haven’t orbited so many guys in SL, it just sounds cool…^^)

[flickr album=72157614945457767 num=5 size=Thumbnail]

Clare Rees (Linden Lab), Hanno Tietgens (Buero X Media Lab), Allison Dollar (Interactive Television Alliance) Axel Hoehnke (Atlas Publisher)

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!

I never was much of a Mac personality. But even then, back in the days of MacOS 7, when I was still hooked on Atari, Win95, and the early Linux, there was a thing that raised my attention: Hey, is it scriptable? Somehow I heard, and that caught my immediate attention, these fancy windowed apps on the funny looking Mac computers could talk to eachother, share their special abilities, and even perform simple tasks without having a user press the buttons. Wow, scriptable. I decided to be a programmer, and chose the “Glue Language” Perl as my matter of subject. (Glue Language meaning: You can take a part of this Website, stuff it into your database, perform some math on it, and make it a nice looking picture on that Website. One would call that “Mashup” today, minus the fancy standardized interfaces, JSON, XML,  XMLRPC…) Anyway, the Glue: Perl, PHP and Python became, and still is my daily work.

Jump to 2006. I just refrained from a Job as a CTO in a big Cisco Training company, where of course I was doing the Glue stuff, Reading and cleaning the MSSQL backend from the CRM, making the CMS talk different languages, spread on different TLDs, and building a fancy new information system and time schedule for the Cisco instructors.

I found Second Life, dived in, and got immersed. And I found a smutty little pearl of scripting language, called LSL (Linden Scripting Language), taking the role of the glue that  “diese Welt im Innersten zusammenhält” (Goethe, Faust I). For a  second time, in this brave new world, I decided to be a scripter, a glue maker, a mashup puppeteer. With our Primforge group, we did such awesome jobs as exporting Second Life Avatars to the weblin World, build the Gamesload Tower of games, a Career Center for a huge consultants agency, an island for a insurance company, that media center for a Radio station, and much, much more.

Building stuff, interconnecting worlds, paring email or twitter, this employee database, your personal website, and that VoIP service to this fancy new island and collaborational meeting place was my job, and I hope that will always be my job. And of course I’m actively scanning for new worlds to conquer  as part of my daily business life.

I still think that all roads begin in Second Life, the one single commercial world, that has all fancy options, and a broad user base. But then, there is OpenSim, the “Apache of Virtual Worlds” as they call it… Back in 2007 some programmers started to reengineer the answer packets, that come from the Second Life sims, and launched a programming project called Opensim. Just like the basic unit of Second Life, one Opensim Simulator creates the virtual space of 256×256 meters land, you can visit with the normal Second Life Client program. But there’s more: With the Grid Server you can host a huge number of opensims, with a common user base, just like the Second Life world. An with the latest Hypergrid, you can even teleport from one hosted Opensim Grid to another. Hypergrid is a coarse protocol, that doesn’t care too much about the permissions of the different Grids that are connected intertwingulary. But there is OGP, the Open Grid Protocol. The guys that invented OGP (mainly from IBM and Linden Lab) are just trying to put together a standardisation request, to make OGP an official protocol, just like HTTP (running the requests from your browser and the answers from my webserver while you read this text) or SMTP (the protocol that receives and transfers your daily emails).

We will soon launch a server farm of Opensim Machines. And I’m really looking forward to glue this all together, our trails of communication in the flat world, the mobile paths, and the new and old 3D worlds.

There’s a new program to capture OpenGL Sessions with Linux, glc. I did some simple tests with it today, and it seems to work very well.

glc-capture  -n  -s  -f 20 -g -o sl2.glc ./secondlife

creates a 800MByte file for a few minutes in SL.

# extract the audio stream

glc-play sl2.glc -o – -a 1 | lame -hV2 – /tmp/audio.mp3

# and make a 2 pass transcoding to a mp3/h264 avi.

glc-play sl2.glc  -o – -y 1 | mencoder -demuxer y4m – -nosound -ovc x264 -x264encopts qp=18:pass=1 -of avi -o /tmp/video.avi

glc-play sl2.glc -o – -y 1 | mencoder -demuxer y4m – -audiofile /tmp/audio.mp3 -oac copy -ovc x264 -x264encopts qp=18:pass=2 -of avi -o /tmp/video.avi

(70MByte for a 2:45 818×636 video)

But we can do better:

ffmpeg2theora /tmp/video.avi -o /tmp/video.ogv

This creates a file of half the size, and directly compatible to the new builtin video support for Firefox3.1 , Ogg/Theora.

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.