About
Members of Linux Australia get up too all kinds of good stuff! Second Life is a fast growing Metaverse that's an amazing place to be and very FOSS friendly.
This site is here so that people can see what the Linux Australia members are doing in-world as well as a resource for Linux users interested in Second Life.
This site is here so that people can see what the Linux Australia members are doing in-world as well as a resource for Linux users interested in Second Life.
Quicksearch
SL News
SL Blogs
SL Reference
Categories
Syndicate This Blog
Is being mute better than a voice without freedom?
Wednesday, June 27. 2007
Linux users of Second Life seeing voice currently being supported in all but their Viewer, are posed with that question.Reading through a job logged in March in the SL JIRA issue tracker titled 'Support Voice on Linux', two things become clear;
1) Linden Lab have licensed Vivox to provide propriety code for Voice.
2) If they ever do support the Linux viewer it will be with a closed 'binary blob'.
To me this seems a real shame. Linden Lab have gone to great lengths to make sure that the technologies they choose to build Second Life are standards based, and as open and transparent as possible.
Recently Sardonyx Linden in a post to the SL Blog thanked the open source community for the work they've done bugfixing the SL Viewer. Linden Lab have gone so far as to GPL the SL viewer including the excellent 'WindLight' code. The Vivox code seems to contrast this attitude starkly.
Vivox appear to have only had limited exposure, their technology being used most notable in another MMOG called 'EVE Online' which doesn't support Linux at all.
I'd love to know why Linden Lab selected Vivox over numerous other open alternatives, as it seems to me that it will only be a matter of time until this code, which is not GPL2 friendly has to be removed and replaced.
What are your thoughts?
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I wasn't involved in the voice planning or development, however I think I can provide some answers to your main question.
The primary reason Vivox was chosen was because of its feature set:
audio quality is good enough to recognize people's distinct voices
multiple sound sources are composited into a single stream on the (Vivox) servers -- this allows for low bandwidth streaming despite having multiple sources
* spatial information of multiple sound sources is embedded into the compressed stream
That last item is important -- a requirement, shall we say, from the perspective of those LL employees who were championing the voice feature.
You mention that there are "numerous other open alternatives". I'm not familiar with the current state of open source audio streaming, so I can't corroborate that statement, however when I asked one of the voice project leaders why they didn't go with a more open system I was told they looked but didn't find any with all the features they needed.
If an open source Vivox equivalent exists, then I suspect it will eventually find its way into SL. I think the current SL-voice feature is free on the mainland (Linden Lab absorbs the cost for voice bandwidth there) but is an extra cost per region on private estates. Therefore, there is a financial incentive for estate owners to deploy an OS voice system (think of it as a different voice "channel" to which SL residents could subscribe). Such a system could be coordinated entirely between the SL clients and the 3rd party audio servers, requiring little or no LL support. (Nevertheless, such an OS voice endeavor would find some support within the LL developer pool.)
If an OS Vivox equivalent does not yet exist then one would hope that the need for one in SL would encourage its development to start soon.
The primary reason Vivox was chosen was because of its feature set:
audio quality is good enough to recognize people's distinct voices
multiple sound sources are composited into a single stream on the (Vivox) servers -- this allows for low bandwidth streaming despite having multiple sources
* spatial information of multiple sound sources is embedded into the compressed stream
That last item is important -- a requirement, shall we say, from the perspective of those LL employees who were championing the voice feature.
You mention that there are "numerous other open alternatives". I'm not familiar with the current state of open source audio streaming, so I can't corroborate that statement, however when I asked one of the voice project leaders why they didn't go with a more open system I was told they looked but didn't find any with all the features they needed.
If an open source Vivox equivalent exists, then I suspect it will eventually find its way into SL. I think the current SL-voice feature is free on the mainland (Linden Lab absorbs the cost for voice bandwidth there) but is an extra cost per region on private estates. Therefore, there is a financial incentive for estate owners to deploy an OS voice system (think of it as a different voice "channel" to which SL residents could subscribe). Such a system could be coordinated entirely between the SL clients and the 3rd party audio servers, requiring little or no LL support. (Nevertheless, such an OS voice endeavor would find some support within the LL developer pool.)
If an OS Vivox equivalent does not yet exist then one would hope that the need for one in SL would encourage its development to start soon.
I can understand the reasons behind LL choosing the Vivox solution. It is uniquely well designed for the sort of environment you have in Second Life. What I do not understand is why this has been released without support for the Linux viewer. Is not Linden Labs in charge? Should they not make it clear to Vivox that their job is not done until the Linux client is fully supported, and withhold payment of real money until such support is provided, if necessary?