[quake3] About adding (VoIP) voice chat support

[Ryan C. Gordon]

> It would be quite difficult. An ingame voice chat system has different 
> requirements
> than a internet telephone, like "many to many" or "many to some" insteed 
> of "one to one" conversations.

I'll preface this by saying that it might be better to build an external 
utility (or adopt an existing one) instead of building it into ioquake3, 
because it would probably require breaking network compatibility to do 
it right. Doing it externally lets you reuse it with other apps, but you 
lose some nice integration features.

The way we did this for UT2004 was simple, but probably 95% of what 
anyone would need:

- You capture audio data with OpenAL. It could be configured to drop the 
gain on the Listener whenever the user was speaking, so they wouldn't 
get feedback and background noise.
- You encode it with Speex, send it to the server one packet at a time.
- Server rebroadcasts the packet to all clients that are presumed to be 
listening. We had a mechanism to make sure packets were reliable and 
ordered over UDP, but I can't remember the details. It was probably just 
built on top of Unreal's networking layer, and Quake3 probably has 
something similar.
- Client received rebroadcasted packet, decodes it with Speex.
- Decoded packet is put onto an OpenAL source's buffer queue.

The system turned out to be pretty elegant...rebroadcasting was 
offloaded to a server, which is presumed to have better 
bandwidth/latency, so the client doesn't have to send the same data to 
everyone playing. The server could make authoritative decisions like "is 
this client within range to hear the message?" if you wanted to do 
radius shouting or "is this client on the same team?" if you wanted to 
do private chatter and reduce bandwidth by not sending when not appropriate.

The clients had options to disable incoming voice, so you could turn off 
annoying people.

OpenAL's buffer queueing mechanism made it easy to deal with dropped 
packets...if we didn't queue it because it didn't show up in time, you'd 
get a small dropout in the incoming chatter, but the system would 
survive. Extra credit for holding packets until either all the 
earlier-ordered ones showed up or you _have_ to feed the buffer queue 
(in which case earlier ones showing up later have to be dropped).

Is there a way to send out-of-band data in Quake3? Perhaps we could put 
it on that, and existing quake3 clients can drop it as bogus data if 
they don't support VoIP...? I don't know the details here.

> Additionally there exists no platform independent sound recording API 
> like SDL for sound playback.

We're adding that to SDL 1.3, and initial framework is in place, but 
it's not ready yet on any platform.

In the meantime, OpenAL 1.0 supports it with the ALC_EXT_capture 
extension, which became part of the base OpenAL 1.1 spec...we used 
ALC_EXT_capture for the VoIP support in UT2004 on Linux and Mac OS X 
(Windows used OpenAL for playback, but recording was done through 
DirectSound directly due to engineering time constraints, but 
ALC_EXT_capture should work on all three platforms).

Anyhow, that's just some notes from a system that worked pretty well out 
of the box for a popular game...I'm not really advocating someone do 
this in ioquake3 unless it really grabs their interest to do so.

--ryan.