Vote for voice protocol documentation (was: Re: [sldev] SLDev-Traffic #24)

[John Hurliman]

I've asked several questions about the voice protocol on this list and 
filed a JIRA for a documentation request when the voice viewer was 
released, I guess the only tool left is voting on the JIRA issue.

http://jira.secondlife.com/browse/VWR-2029

Also, can we move the voice discussion beyond bringing up Speex or other 
free codecs until someone can prove that these will actually work with 
Vivox servers? Linden Labs did not write the voice code, they don't own 
any of the patents, and they don't run any of the VoIP servers. Asking 
them to switch to brand X isn't going to accomplish anything.

The line between free and non-free has currently been drawn at the 
XML-over-TCP pipe from the SL viewer to the SLVoice daemon. In theory 
this line could be pushed further since most of the voice architecture 
is built on free software and the codec and 3D positional algorithms 
from DiamondWare are the only truly non-free bits I've found, but I'm 
not yet convinced that there's any benefit to reverse engineering the 
voice daemon for the purposes of using with the official viewer. It 
doesn't solve any of the original problems with patented algorithms and 
doesn't make alternative platform clients any more feasible. The only 
benefit there would be for libsecondlife bots to have lower level access 
to the Vivox API and hopefully be able to inject/extract raw audio streams.

John Hurliman


Dana Fagerstrom wrote:
> I'd like to second (or third) the request for more details on how 
> voice is "strapped" into the viewer.
> D
>
> Chance Unknown wrote:
>> There are a number of full rate codecs that are compatible with VOIP
>> telephony. One that is used quite frequently, and that you can find
>> implemented in open source VOIP products is GSM729 and the ilk. A
>> resonable codec needs to have adequate noise suppression and suitable
>> bandwidth for its intended use. Full rate codecs are both wasteful of
>> data bandwidth and generally do not offer better sound quality for
>> speech.
>>
>> I would be much more interested on the documentation of LL's
>> integration effort and documentation of the API where the viewer
>> connects to the voice infrastructure, and what messaging is with
>> respect to the SIM is passed to the viewer (and on to the voice stream
>> if required). This would allow open source people to be able to better
>> understand the requirements, and to possibly make more sophisticated
>> optimizations within the viewer. -- Example: running the daemon under
>> wine, but the SL client native on linux...
>>
>> ==
>>
>> On 8/15/07, Callum Lerwick <seg at haxxed.com> wrote:
>>> On Wed, 2007-08-15 at 11:47 -0700, Chance Unknown wrote:
>>>> The magic of analog to digital conversion of voice is performed by the
>>>> Codec. There are a number of opensource alternative codecs available,
>>>> but they are far from optimum for very specific use cases.
>>> Is there something wrong with Speex?
>>>
>>> The problem is not simply a matter of open/closed source, from what
>>> we've been told the primary codec in use is patented encumbered, thus
>>> even if we had a 100% open source, clean-room engineered implementation
>>> of the codec, we still couldn't distribute it in Fedora unless the
>>> patent holder gives a legally binding, written, irrevocable, perpetual,
>>> royalty free license grant for use by any and all Open Source software.
>>>
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> /index.html
>>>
>>>
>>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>