Vivox, Unity, and the viewer's positional audio

[Ricky]

Just curious how, if at all, the changeover of Vivox to Unity and their shutdown of some aspects of the service might affect the viewers and LL.

I suspect that LL has probably either had their contract grandfathered or renegotiated with the new owners, I know I would: doesn't take valuable engineering time.

However, those running other grid services might not be able to handle the licensing changes. There's the OpenSim conversion to Mumble as an alternative, but that takes changing out the SLVoice executable in the viewers.

[Beq Janus]

I think that this has very little to do with "new" (Unity bought Vivox in early 2019) ownership and a lot to do with not wanting to keep having legacy software supported when there is no revenue to be derived from it. 

Vivox4 is considerably out of date and they want to focus resources on Vivox5. For OpenSim, Vivox4 is just a cost, so eliminating the overhead and moving it onto the same shared server infrastructure as the rest of their indie free tier clients makes a lot of sense. For LL there is a difference, LL is a paying customer and within certain limits that affords an extended support period.

The larger problem is purely technical, there is no back compatibility between Vivox5 and Vivox4. I do not know whether this is simply because they are on separate infrastructures because they have fundamentally different wire formats or a mixture of both; but what this means is that there is no migration path for a service that may have users on older viewers and newer viewers simultaneously. 

The most palatable solution to the problem above would appear to be the same as the suggested "Mumble" solution; i.e. the distribution of a standalone "slvoice" updater that installs a new slvoice-like service. I have been told that Mumble lacks features compared to Vivox though but not seen a feature comparison table.

It is easy enough for the viewers to add a configuration setting to support the selection of alternative voice services so long as the communication between the viewer and the voice service remains consistent, that is my plan for FS on OpenSim once there is a viable option. I've not looked closely enough at how this all works to know if that is the entire story though, i.e. I'm unsure at the moment whether the API between viewer and voice service executable is a full abstraction or not?

Beq

--
Archives of earlier incarnations of this list are at https://list-archives.secondlife.com
---
You received this message because you are subscribed to the Google Groups "opensource-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensource-de...@lists.secondlife.com.
To view this discussion on the web visit https://groups.google.com/a/lists.secondlife.com/d/msgid/opensource-dev/CAFsNfZ%2B2MDyr%2BNv%3D3xfgEL7TnzWmy7_JZQqqY3Z5DHnOdUkBDA%40mail.gmail.com.

[Sitearm]

fyi only... another bit of evidence Vivox is working to improve product and service for its paying customers... experimental viewer release notes sent to me by a colleague... we do weekly open mics together in this 3d platform

...Just found this, released (apparently) about a month ago - A version of the viewer that lets you turn off automatic voice detection and/or modify its sensitivity. Have not had time enough to experiment with this, but maybe making adjustments to these settings can finally allow music to go through voice without the usual frequent dropouts 

https://releasenotes.secondlife.com/viewer/6.4.19.559726.html

6.4.19.559726 - Maintenance2
Wednesday, May 19, 2021

Voice Activity Detection This Viewer also exposes four VIVOX VAD (Voice Activity Detection) variables via Debug Settings and disables the (previously enabled) automatic mode. By making changes to these variables, we should be able to come up with a collection of settings that we can base new default values on in settings.xml. The Debug Settings are: VivoxVadAuto Enable (1) or disable (0) automatic VAD. If this is disabled, the voice characteristics can be changed by adjusting the other settings. If this is enabled, modifying the other settings will have no effect. VivoxVadHangover The time (in milliseconds) that it takes for the VAD to switch back to silence from speech mode after the last speech frame has been detected. VivoxVadNoiseFloor A dimensionless value between 0 and 20000 (default 576) that controls the maximum level at which the noise floor may be set at by the VAD’s noise tracking. Too low of a value will make noise tracking ineffective (A value of 0 disables noise tracking and the VAD then relies purely on the sensitivity property). Too high of a value will make long speech classifiable as noise. VivoxVadSensitivity A dimensionless value between 0 and 100, indicating the ‘sensitivity of the VAD’. Increasing this value corresponds to decreasing the sensitivity of the VAD (i.e. ‘0’ is most sensitive, while 100 is ‘least sensitive’) The default values (updated) are (using VIVOX names): VadHangover(s): 2000 (Valid values are 1 - 60000 milliseconds) VadSensitivity: 0 (Was 43 - valid values are 0 - 100) VadNoiseFloor: 576 (Valid values are 0 - 20000) Some of the settings can only be changed by restarting the Viewer or teleporting away and coming back (needs a new voice connection) but the other 2 work in real time as you change them. Early testing suggests that VivoxVadNoiseFloor needs the restart or teleport to stick. After some initial testing with VIVOX, they suggested starting from a point where VivoxVadSensitivity was set to 0. This will likely result in no dropouts because the microphone is sending everything to the voice channel. However, in a noisy environment (talking in background, vacuum cleaner, TV on etc.) it will also transmit that too. Though with modern microphones, that have built in noise cancellation, sending everything may be a good thing as the microphone may have done all the heavy lifting of noise cancellation first. Please let us know what VAD Sensitivity value works best for you!

--

[Henri Beauchamp]

On Tue, 15 Jun 2021 08:05:08 -0500, Sitearm wrote:

> fyi only... another bit of evidence Vivox is working to improve product and
> service for its paying customers... experimental viewer release notes sent
> to me by a colleague... we do weekly open mics together in this 3d platform
>
> ...Just found this, released (apparently) about a month ago - A version of
> the viewer that lets you turn off automatic voice detection and/or modify
> its sensitivity.

This is not a proof of (or evidence for) anything... These settings might as
well have existed for years already but were simply not yet used by the viewer
(i.e. VAD was by default left on auto so far).

Henri.

[Henri Beauchamp]

On Tue, 15 Jun 2021 14:00:39 +0100, Beq Janus wrote:

> The most palatable solution to the problem above would appear to be the
> same as the suggested "Mumble" solution; i.e. the distribution of a
> standalone "slvoice" updater that installs a new slvoice-like service. I
> have been told that Mumble lacks features compared to Vivox though but not
> seen a feature comparison table.
>
> It is easy enough for the viewers to add a configuration setting to support
> the selection of alternative voice services so long as the communication
> between the viewer and the voice service remains consistent, that is my
> plan for FS on OpenSim once there is a viable option. I've not looked
> closely enough at how this all works to know if that is the entire story
> though, i.e. I'm unsure at the moment whether the API between viewer and
> voice service executable is a full abstraction or not?

I doubt coding a protocol translator/wrapper to make a different voice
client appear (from the viewer point of view) as a Vivox client is a very
practical or even legally usable (*) everywhere...

Rewriting the protocol glue code in the viewer for a new voice client is
not that hard, but it would of course not cover the interoperability issue
with old viewers (this said, maintained viewers will likely quickly update
to stay compatible, so not really a dramatic issue).
There may also be consequences on the viewers UI, if some functionalities
are not supported or are implemented very differently in the new client
(and a wrapper/translator won't plug that issue).

The really *important* thing is that OpenSim folks and LL do speak together
and come up with an agreement about the next voice client, so that we (TPV
devels) do not end up with a double implementation (won't be the first one,
but still...).
Hopefully, and preferably, the new voice service will also support all OSes
(Linux included !), unlike Vivox.

Henri.

(*) I.e. is the Vivox protocol patented ?... Not a problem in the UE,
where software patents are (thankfully !) illegal, but in the USA,
it'd be another story...

[Beq Janus]

On Tue, 15 Jun 2021 at 14:42, Henri Beauchamp <sl...@free.fr> wrote:

On Tue, 15 Jun 2021 14:00:39 +0100, Beq Janus wrote:

> The most palatable solution to the problem above would appear to be the
> same as the suggested "Mumble" solution; i.e. the distribution of a
> standalone "slvoice" updater that installs a new slvoice-like service. I
> have been told that Mumble lacks features compared to Vivox though but not
> seen a feature comparison table.
>
> It is easy enough for the viewers to add a configuration setting to support
> the selection of alternative voice services so long as the communication
> between the viewer and the voice service remains consistent, that is my
> plan for FS on OpenSim once there is a viable option. I've not looked
> closely enough at how this all works to know if that is the entire story
> though, i.e. I'm unsure at the moment whether the API between viewer and
> voice service executable is a full abstraction or not?

I doubt coding a protocol translator/wrapper to make a different voice
client appear (from the viewer point of view) as a Vivox client is a very
practical or even legally usable (*) everywhere...

This is not about anything owned by Vivox, slvoice.exe is an open-source voice service plugin, this is simply about replacing that and using the same API/ABI between the executables.

The solution used in the past looked like this

(Image taken from the OSCON 2019 presentation by IMA/Thales.)

It was then extended it interpose a "voice switch" bridge that effectively allowed a voice service selection to be made outside of the viewer. This has the benefit of not being dependent on the viewer nd thus allowing it to be backward compatible (ish)

That work was undertaken independently of the Thales works (as best I can tell) by Seth Nygard it works as shown here

https://gyazo.com/d6645cdda9366724702def75f3dfaa39

(image taken from the OSCON 2019 presentation)

 the full video can be watched here https://www.youtube.com/watch?v=hL3ebPfMU10

Rewriting the protocol glue code in the viewer for a new voice client is
not that hard, but it would of course not cover the interoperability issue
with old viewers (this said, maintained viewers will likely quickly update
to stay compatible, so not really a dramatic issue).
There may also be consequences on the viewers UI, if some functionalities
are not supported or are implemented very differently in the new client
(and a wrapper/translator won't plug that issue).

The bridge solution does provide some form of backward compatibility as the bridge detects the region change and determines the correct voice service to use. 

It does not, of course, solve the interoperability issues but that is probably not a major issue once you have the auto-switcher in place, it certainly eases the pain.

The really *important* thing is that OpenSim folks and LL do speak together
and come up with an agreement about the next voice client, so that we (TPV
devels) do not end up with a double implementation (won't be the first one,
but still...).
Hopefully, and preferably, the new voice service will also support all OSes
(Linux included !), unlike Vivox.

100% agree, it would be good to ensure that the API in the viewer is frozen/standardised such that all viewers can use different voice services.  

Beq 

[Henri Beauchamp]

On Tue, 15 Jun 2021 15:17:16 +0100, Beq Janus wrote:

> This is not about anything owned by Vivox, slvoice.exe is an
> open-source voice service plugin,

Open-Source, really ?... Show me the sources, please !... If it
was Open Source, a supported Linux version would exist already. :-P

Plus, the protocol used by the Vivox client to communicate with
the viewer might be patented or not: only Vivox & LL could tell.

As for keeping the old protocol between the viewer and the next
voice client, it might sound appealing, but will likely cause
more headaches (what about unsupported or new features, and their
UI incarnations in the viewer ?) than simply rewriting the voice
client code (llvoicevivox.* in v2+ viewers, part of
llvoiceclient.* in mine) in the viewer for the new protocol, then
adapting any UI element that needs change...

Just my two cents, of course.

Henri.

[Beq Janus]

On Tue, 15 Jun 2021 at 16:48, Henri Beauchamp <sl...@free.fr> wrote:

On Tue, 15 Jun 2021 15:17:16 +0100, Beq Janus wrote:

> This is not about anything owned by Vivox, slvoice.exe is an
> open-source voice service plugin,

Open-Source, really ?... Show me the sources, please !... If it
was Open Source, a supported Linux version would exist already. :-P

Sorry, I should be more careful about my words and meaning. 

The manner in which the slvoice service is spoken to is open-source, 

You are correct, that we should not assume that the interface between viewer and voice plugin is IP free we can at least clarify that. 

It would be interesting to see it defended too. Google and Oracle have had much fun over this. :-)

My point was that where there has been talk of "reverse engineering" and "packet capture" with regard to Vivox voice, that is almost certainly deep into the legal badlands and is simply the wrong path to be following when we already have the source code for an API/ABI.

 

As for keeping the old protocol between the viewer and the next
voice client, it might sound appealing, but will likely cause
more headaches (what about unsupported or new features, and their
UI incarnations in the viewer ?) than simply rewriting the voice
client code (llvoicevivox.* in v2+ viewers, part of
llvoiceclient.* in mine) in the viewer for the new protocol, then
adapting any UI element that needs change...

Yes maybe, and yet if we want an abstraction that removes vendor lock-in then some form of standard is needed.

The idea of keeping what we have, at least as a version 1 implementation, is to allow a migration path.

As with all good API design, versioning is key to allowing compatibility over time.