Long-term future of SLVoice.

[arabellajones]

It is my understanding that voice in Second Life depends on a module supplied through Linden Lab, which uses proprietary code from Vivox. All third party viewers depend on this code and use a module called "SLVoice", marked as an executable.

I have not seen any clear statement of when this code was last updated. While Linux support is suspended, and a future "Alex Ivy" viewer for Linux depends on work from the TPV community, which I see is being done, this particular component appears to depend on Linux code that ceased maintenance four years ago. I refer to the gstreamer-0.10 module.

It already appears not to work any more.

Since it is not open source there is an obvious problem in an update depending on the TPV community.

I can see a couple of possible fixes, but they depend on there being a legal way for somebody to work with the Vivox code. Essentially, it needs somebody with Linux skills to do the work under contract, but is it Vivox or Linden Lab who has to employ them.

While there are similarities with the situation over the Havok code for mesh import, I would argue that Voice is not the same. We don't need to agree extra T&Cs to use Voice, as we do to import mesh.

 

Is there a long term plan, or should I assume that voice is now a dead option for Linux viewers? Should Voice be assumed by event organisers to be a universal (I hit problems at SL15B, where presentations by Linden Lab used Voice with no apparent alternative.)

(Having somebody speaking on a media stream while listening for questions on voice could be a fix for these big events, but you would need to be careful about feedback loops.)

The voice problem also raises questions about the regular in-world user group meetings. I am not enthusiastic about using Windows for a special event, but if it is going to be necessary, I would prefer something a little bit more explicit than saying Voice is used. It isn't working with Linux. Say these events don't work with Linux viewers.

 

 

[Fionalein]

28 minutes ago, arabellajones said:

The voice problem also raises questions about the regular in-world user group meetings. I am not enthusiastic about using Windows for a special event, but if it is going to be necessary, I would prefer something a little bit more explicit than saying Voice is used. It isn't working with Linux. Say these events don't work with Linux viewers.

So do the project viewers - everything there is right now pretty MS biased... I will work with BOM and animesh once TPVs get it. I will not bother to set up something like a project viewer in wine.

[Coffee Pancake]

Right now Linux support from LL is on the rocks and the viewer listed as obsolete. LL events that require voice do so on the understanding that all supported platforms have fully functional voice services.

There're plans to build the viewer standalone using system libraries and providing packages/repositories for major distributions, however .. LL do require community help in order to advance this project. I.E The community makes it work (standalone will require changes to viewer code) and LL will adopt their changes, add it to their build platform and return to officially supporting it. 

Firestorm are pretty much the only game in town when it comes to continued Linux support and it's not getting any easier for them to continue to provide a native client.

Running the Windows client with Wine does provide a decent experience if you can ignore that OCD itch.

[arabellajones]

1 hour ago, CoffeeDujour said:

Running the Windows client with Wine does provide a decent experience if you can ignore that OCD itch.

Some companies do it right. They take the trouble to test their product. For them, Wine is effectively another version of Windows. I use one of these programs.

Some of the choices Linden Lab have made make it a little difficult for me to regard them as competent.

[animats]

3 hours ago, CoffeeDujour said:

There're plans to build the viewer standalone using system libraries and providing packages/repositories for major distributions, however .. LL do require community help in order to advance this project. I.E The community makes it work (standalone will require changes to viewer code) and LL will adopt their changes, add it to their build platform and return to officially supporting it. 

Firestorm are pretty much the only game in town when it comes to continued Linux support and it's not getting any easier for them to continue to provide a native client.

Running the Windows client with Wine does provide a decent experience if you can ignore that OCD itch.

Right now, self-compiled Firestorm, which does not have Havok or Kakadu, is almost there on Linux. I had to add one fix. to stop the "5-component texture crash", and 5.1.5 has then run for weeks now on Linux without trouble. LL is moving away from Kakadu to OpenJPEG, which is a win for Firestorm; the Firestorm organization claims over half their revenue goes to the Kakadu license, which really isn't necessary any more.

Vivox, though, is a service. The voice switching and processing happens on Vivox servers. And Vivox, the company, dropped Linux support in 2016. There are Vivox alternatives, but switching would be a big deal. Maybe after the move to AWS, LL could switch to some self-hosted solution like FreeSwitch and dump Vivox.

 

[Coffee Pancake]

The linux client needs to be be built standalone with zero bundled libs, if you're up for an adventure...

[animats]

The SL viewer just sends XML to the separate SLVoice  program to tell it who to talk to. So replacing SLVoice with another VoIP phone system could be done by building a program that wraps a FreeSwitch client, or some other open VoIP conferencing system.

Is Northbridge Business Systems , Second LIfe's telephone company, still active? Maybe they could take over voice.

Edited June 29, 2018 by animats
Generalize

[Coffee Pancake]

Any viewer that implemented a third party voice client in addition to or replacement of the official vivox client would get a nuke in the mail from LL pretty sharpish as it would break TPV shared experience rules.

[arabellajones]

On 28/06/2018 at 5:47 PM, animats said:

Vivox, though, is a service. The voice switching and processing happens on Vivox servers. And Vivox, the company, dropped Linux support in 2016. There are Vivox alternatives, but switching would be a big deal. Maybe after the move to AWS, LL could switch to some self-hosted solution like FreeSwitch and dump Vivox.

 

I don't think I've seen anything elsewhere to say Vivox no longer support Linux. It makes all the talk of a community-supported Linux version look a bit of a sham. It was easy enough to confirm through Google, but it's all indirect. All you can see from Vivox is total silence about Linux.

I'd be a bit less grumpy if Linden Lab were at least honest about this detail. They seem to have a devotion to voice, which I am not sure is all that useful in practice, and I can't help but recall that line about a verbal contract not being worth the paper it's written on. After my experience of SL15B, it looks like part of a larger pattern of bloody-minded non-information.

I know that as a Linux user I am in a tiny minority, but I reckon the problems I have would be the same, or worse, under Windows. Switching won't, for instance, change the quality of the documentation for Second Life.

[animats]

24 minutes ago, arabellajones said:

I don't think I've seen anything elsewhere to say Vivox no longer support Linux. It makes all the talk of a community-supported Linux version look a bit of a sham. It was easy enough to confirm through Google, but it's all indirect. All you can see from Vivox is total silence about Linux

Here's a third party viewer meeting where Oz Linden brought this up back in 2016.

Vivox, total silence, yes. They just quietly removed the icon from a page of icons. That's surprising from Vivox, because they support Unreal Engine, which is fully supported on Linux.

Not many end users use Linux, but many developers do. The tools are better.

Several of the OpenSim grids use FreeSwitch. DoD, amusingly, which used OpenSim for training and didn't want their voice going through Vivox servers. So the necessary code already exists.

It's an ongoing problem for a long-lived product like SL. Vendors come, vendors go, and you can't be too dependent on third parties.

Edited June 30, 2018 by animats
More info

[arabellajones]

On 30/06/2018 at 7:56 PM, animats said:

Here's a third party viewer meeting where Oz Linden brought this up back in 2016.

 

It's arguable that there needs to be something better than these meetings, coming from Linden Lab. Some things get clearly announced. Some don't.

This is one of the things that got left to drift, and I don't think it should have been.

I hope they're paying Inara Pey really well for reporting these events, and doing the job that they should be.

[Coffee Pancake]

Voice status and updates have not been left to "drift", There is a internal voice viewer with updates from vivox and pending a further update from them will be released in the not too distant future. Maintaining and improving voice is important to LL and TPV's and the issue routinely gets brought up at meetings ... which you are free to attend.

If you cant, they are recorded and placed on YT  https://www.youtube.com/user/PanteraPolnocy/videos

Vivox updates can be seen here https://youtu.be/quejAR7VaRE?t=1132

 

 

LL would like to resume issuing a Linux viewer in line with Windows & OSX but need community help to do it, they have been asking for help for a year at this point. The viewer has many dependencies, right now these are compiled for and shipped with the viewer binary, this needs to be changed so the viewer will uses system libs like every other Linux application. If you have the time, skill and would like to do something constructive .... you will find LL and the remaining few Linux TPV devs very receptive. Feel free to get the source and have at it (I would recommend a debian based build environment and leaving openjpeg till last).

 

The contents of TPV meetings are generally not announced as are often very dry, technical, and of little interest to most users. We (as TPV developers) need to know what's in the pipeline, when releases are planned, what LL updates we need to pay special attention to, service changes etc etc. There is discussion about code or projects we are submitting to be included with the LL client, a process that takes significant time. Likewise it gives us opportunity to raise issues with LL. Most discussion is weeks, if not months away from affecting end users. ... Seriously watch a few meetings, whats to announce ... "working on stuff Linden is working on stuff" or "please don't update your viewer next week as our support staff are on holiday".

 

The only people getting paid have an account name ending in "Linden", everyone else does this for funsies.