Suwwy guys, primforge.com was having a short downtime earlier this day, therefore our online services and the SLInside Panel were affected..

Meine schöne Uptime… Naja, nach 300 Tagen braucht soger ein Torrid-proof Gentoo-Linuxrechner mal einen Reboot ^.~
Der Apache war heute vormittag kurzzeitig nicht ansprechbar, daher kam es in den SLInside-Panels zu Fehlermeldungen.

Sincerely,
Your Administress

The spring of hope

You might already have sensed that from the sparse traces in our recent twitter and blog posts. Anyway, Primforge is going virtyoual! We have been planning this for almost a year now, and in the last days, we actually founded the virtyou GmbH, a RL company here in Berlin/Germany, backing up on our work in Second Life and other virtual worlds.

Currently we are active building our company infrastructure, the virtyou Metagrid, and supporting our customers weblin, and theProjectfactory as well as our new clients, theDOgroup and DBC GmbH.

What’s changing?

Um, nothing, and then some. As a group in Second Life, we’ve been having many good ideas regarding media convergence, communication technologies and so on. But we always needed a  customer, an order and a “GO”, to actually investigate time and money into development.

Now, with a backing of some x0.000 US Dollars, we are free in several directions, modeling our ideas of a decent metaverse, both in Second Life and our virtyou Maingrid, and we are still available for our customers, to do the awesome development work we are famous for.

Can I contact you?

• Yes, very much so! :-]
• We are rl-ish available at the bunch of conferences taking place in Berlin in the next weeks, see Upcoming Virtual Worlds meetings in Berlin.
• Log into our new virtyou Maingrid and talk to us in-world.
• Contact us in Second Life: IM Torrid Luna, or Marcuse Bloch.
• Use our Contact form.

Where will it all end?

In his current blog post, Jack Linden decides wisely how to cope with bots:

• Use of Bots to game Traffic will be considered a violation.
• Bots are fine and we totally support their good use inworld, but we will deal with inappropriate use of them.
• Traffic has value as a land metric, and will remain.
• Responsible use of Land Bots is acceptable for now, but overuse will result in further action.

Note, that this is not a technical solution, but rather a guideline to the community, just as I proclaimed on JIRA and slinfo.de back in mid-2008.

On the other hand you could say, they just forbid what they can monitor. (Since of course they can monitor unusual Traffic spikes easily, but it would be much harder to data-mine land sales.)

Anyway, I’m happy with it for now, and my chat bot, and the ZKM project are not threatened, phew.

I just found this in an article by Gary P Hayes, introducing the calculation of the Tweet-GQ (Twitter Gary Quotient):

( ((Following/3)+Followers) x (Followers/Updates) ) / 10

This formula gives Torrid Luna a Tweet-GQ of 9.0, well, OK.^^

Anyway, the Mosaic is awesome, greetings to you, fellow followers!

Get your twitter mosaic here.

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…^^)

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 been teleporting around the smashing new Hypergrid experience this last night, and all I can say: Watch out, Second Life! All reasoning saying that Opensim would split the small scene into so many divided grids and cultures is nonexistent for me from today on. And OpenSimulator actually is the Apache of 3D environments.

Ah, and a Happy Birthday to OpenSimulator!