SL voice on linux

Hi!
I am a little worried because Linux is never mentioned when you do announces about the new voice feature...
you always talk about win and macs but are you going to release a voice-compatible linux SL client?

Lanz

A simple search would of given you this answer: Until Vivox gives them a Linux binary to link against, there won't be a voice client.

Choosing a closed and proprietary solution for voice, after having open-sourced the client, sounds like the height of .... inconsistency. Something doesn't quite add up here.

Let's hope that there is some kind of interoperability plan in the works, otherwise the open-source folks have just been relegated to the ghetto.

Morg.

From the blog:

So... are they expecting Vivox to get the Linux version done in that interval? I really wish they'd either explicitly stated that Vivox has to get busy and have a working Linux client by then, or explicitly stated that Linux users will be able to run a voiceless client if it's not ready by the time they get that good feedback and have the bugs fixed.

If Vivox cares so little about meeting their Linux obligation towards Linden Labs, why shuld Linden Labs do business with them? LL should refuse to release voice until Vivox has provided Linux support... or else they should admit they don't really care about Linux users afterall. It would be nice to hear some feedback about this. It's not nice being left in the dark.

I don't really feel the need for a voice client, but I can understand the concerns about "true support" coming from Linux folks.

However, stop for a second and think: did LL ever commit themselves to provide a complete Linux client?

I don't know the answer, or maybe - like most people here - I don't want to see the answer that has been already given us in form of countless hints.

Sculpties? For Win and Mac . New sky rendering tech? For Win and Mac . New beta grid client? For Win and Mac . New voice feature? For Win and Mac.

We have an alpha client not because the quality is alpha: on the contrary, our little toy leaves the win client in the dust. I start thinking we have a client called alpha so we don't complain too much when feature availabilty is lacking: "It's an alpha client, what else do you want?"
___

Now for Linux, too.

Just as long as they remember that Linux users are usually tech oriented and talking to people about software a LOT. Night before last I was at a party and the topic of ISP's came up which led to gaming and one person mentioned that he was going to try World of Warcraft with his wife and brother and in front of 8 people I told him to look at SecondLife.

That is eight word of mouth referals in one day.
I doubt I would be thinking to make mention of something I didn't use.

Has anyone checked the API that's been used within the client for interfacing to Vivox's code?

The really key issue in all of this is whether interoperability for voice has been designed-in by LL, so that an open-source solution for Linux can be retrofitted later either by LL or by the community.

If the client is actually hardwired to Vivox API calls, rather than accessed through a generic API, then LL designers need to be flagellated so hard until it bleeds (or reconnected to their coffee drip-feed, as they've gone to sleep). But hopefully it's not so, and they've thought ahead.

(Interoperability with Vivox audio streams is presupposed as well of course, but I'm assuming that LL would not have chosen a voice system with a closed stream specification, since that would fragment the population.)

Morg.

Actually, sculpties do work in the linux client. Atleast they work fine for me.

I can confirm sculpties certainly work on the Linux client. The new sky-rendering tech, however, I'm not so clear on. I think I have to comment out "export LL_GL_BASICEXT=x" in the secondlife run script to find out.

Why are we actually guessing what the situation is with voice and Linux, and about what LL has planned for interoperation between Vivox-powered clients and clients using open-source voice code?

LL tend to be pretty open about about their plans. We just have to ASK the right person.

Morg.

why LL chose quicktime instead of open video formats such as xvid or ogg/theora?
there are open sound formats as well...

Maybe the left hand doesn't know what the right hand is doing in LL, or perhaps someone is actively trying to subvert the stated policy.

There's no doubt that Philip wanted the client to go open-source, he said so on numerous occasions. Yet some LL designers seem to be heading in diametrically the opposite direction, making the open-source version a crippled build through choosing closed proprietary subsystems which (presumably) cannot be open-sourced.

I guess the conspiracy theory interpretation that they want the kudos of going open source and want the community contributions, but don't actually want community-built clients to be used, is a theoretical possibility, but it doesn't seem a genuine one to me. It's more likely that a top-rank LL dev is not a Linux nor open-source fan, and is rocking the boat a bit by knowingly making choices to our detriment.

Or possibly no conspiracy theories needed, and there's just a very bad internal disconnect in the dev team and it's being done by accident.

Anyway, the situation isn't good.

Morg.

OTOH, the just released Linux FirstLook viewer has WindLight (aka "pretty sky" support.

As Morgaine said, quite contradictory signals come from the top brass...

I guess sip protocol is very solid.
Do we need a petition to get it implemented in SL?
Regarding quicktime video I read it could be solved thanks to gstreamer...

Isn't that just "solved" for x86-based Linux users, because there's a hack to use the Windows versions of proprietary libraries?

It may work as a hack for the binary alpha Linux client, but it's certainly not a viable solution for the open-source client. And they are of course one and the same codebase.

I'm still hoping to find that LL has created a generic voice API layer, with the proprietary Vivox interfacing being done in special code beneath that. If so, then we'll be able to plug in an open voice subsystem in place of Vivox's closed module in due course, assuming that Vivox's streams are interoperable of course.

The jury is still out.

Morg.