This article follows "Vivox in SL: client, server and protocols". Here, I focus on the client components and how they interact to enable voice in SL.
SLVoiceAgent.exe could not be found in the 1.23.5 SL client, however it is mentioned several times. The roles of other files such as tntk.dll or srtp.dll are not clearly mentioned in the SL wiki, but other SL viewers such as Hippo mention them as
vivox_files. Mike Monkowski reported in the SLdev mailing list of September 2007 that srtp.dll and tntk.dll
are part of the DiamondWare distribution, but don't appear to be used by SLVoiceAgent. My guess is they were redundant with other components.
|srtp.dll||ortp.dll provides RTP, making srtp.dll useless. Not present in the 1.23.5 Viewer.|
|tntk.dll||I could not find what services tntk.dll provides, so I do not know which other library could have made it redundant. Not present in the 1.23.5 Viewer.|
|ssleay32.dll and libeay32.dll||Other libraries such as ssleay32.dll or libeay32.dll mentioned in the Third-party libraries wiki page may have been replaced by ssl3.dll in the 1.23.5 Viewer. Not present in the 1.23.5 Viewer.|
consists of a client SDK and a high-performance server. It was designed to be extensible via plugins on the client-side and 'bots on the server-side [...] Plugins and 'bots can be created by third-parties thereby leveraging the game development. The client-side is composed of VoIP building blocks. Diamondware seems perfect for a game integration. If it is present in the 1.23.5 Viewer, I could not find in which client-side component it was.
By "used components", I mean the v1.23.5 SL client components mentioned in the Third-party libraries of SL without the "unused ones" mentioned above.
|alut.dll and wrap_oal.dll||
OpenAL's primary use is assumed to be for spatialized sample-based audio. Quite many platforms, engines and games use OpenAL as a LGPL 3D audio API. OpenAL relies on three objects: Buffer, Source and Listener (see OpenAL 1.1 Specification and Reference and the conceptual class diagram nearby). The OpenAL HelloWorld explains a lot. I think some functions in alut.dll (the ALUT library) might be called by wrap_oal.dll, but I am not sure.
|ortp.dll||ortp is a LGPL library. It is apparently part of the amsip toolkit (but it can be found outside of amsip) and provides the protocol layer primitives: SIP, RTP and ICE. These protocols were described in a previous article.|
|vivoxsdk.dll||Uses the proprietary Siren14 codec by Polycom and relies on ortp.dll, alut.dll and wrap_oal.dll.|
external daemon software started and stopped by the Second Life Viewer(SL wiki). More precisely, SLVoice.exe is a daemon that receives calls from the SL Viewer through a local TCP server (default is 127.0.0.1:44124). Also named client gateway, SLVoice.exe is the proprietary black box that communicates with the Vivox servers.
FMOD is a 3D audio engine. The SL client contains fmod.dll which is, to my mind, used to play in-game sounds, eventually in 3D. Some of fmod features such as 3D or channel groups might be provided by the Vivox SDK as well. This is a problem with using third-party libraries: their features sometimes overlap.
There are some remarkable differences between the v1.23.5 and the beta v2 SL clients concerning the voice components. For instance, the v2 beta client contains ortp.dll, vivoxoal.dll, vivoxplatform.dll, vivoxsdk.dll and SLVoice.exe. vivoxoal.dll may gather alut.dll and wrap_oal.dll, but I have no idea what new content vivoxplatform.dll can bring. I only focused on the 1.23.5 files mentioned in the documentation.
Interaction between components
The messages sent from the Viewer to the gateway are based on the SLVoice Application 2.0 documentation.
Diagrams made with Dia. There are many things I tried to guess about this architecture, so feel free to tell me if I am wrong anywhere.