VOIP Support in SVN

Lets examine two quick points:

• Hardcore gamers like choices.
• Hardcore gamers like VOIP.

Based on these theories, ioquake3 is adding VOIP support for the next release. This internal support is going to bring along with it support for (entirely optional) Mumble positional VOIP audio. More nerd-speak after the break, the short and quick of it is, however:

We’re going to have VOIP for mods/new games, and baseq3. This is a pretty radical departure from the initial goal of not changing anything in baseq3, and is probably the single largest (obvious) end-user benefit for using ioquake3.
The fact of the matter is that if you want to blame someone for allowing it to be included, you can blame me (Zachary, lead omnipresent overseer of ioquake and related entities). If, however, this makes you happy and you want to praise somebody, give either big ups OR big props to Ryan Gordon (lead intergalactic space nerd) and Ludwig (Herr Angst).
Please, do not spoil them with both ups AND props.
 

Ryan “icculux” Gordon started it off with this post to the mailing list:

I promised this to zakk like 18 years ago.
Here's a first shot at VoIP support. It's still pretty rough, but it's
just meant to be the groundwork. Patches are against svn revision #1345.
This requires patched builds to be useful, but remains network
compatible with legacy quake3 clients and servers. Clients and servers
both report in their info strings whether they support VoIP, and won't
send VoIP data to those not reporting support. If a stray VoIP packet
makes it to a legacy build, it might print an error to the console, but
should continue on anyhow.
Data is processed using the Speex narrowband codec, and should be
cross-platform. Bigendian and littleendian systems can speak to each
other, as can 32 and 64-bit platforms.
Bandwidth: VoIP data is broken up into 20 millisecond frames (this is a
Speex requirement), and we try to push up to 12 Speex frames in one UDP
packet (about a quarter of a second of audio)...we're using the
narrowband codec: 8000Hz sample rate. In practice, a client should send
about 2 kilobytes per second more when speaking, spread over about four
bursts per second, plus a few bytes of state information. For
comparison, this is less than the server sends when downloading files to
the client without an http redirect. The server needs to rebroadcast the
packet to all clients that should receive it (which may be less than the
total connected players), so servers should assume they'll need to push
(number of players speaking at once times number of people that should
hear it) * 2 kilobytes per second. It shouldn't be a problem for any
client or server on a broadband connection, although it may be painful
for dialup users (but then again, everything is. They can just disable
the cvar).
Clients can choose to ignore specific players, or everyone, which
instructs the server to stop sending ignored packets to the ignoring
client, to save bandwidth. Although unimplemented, there are hooks for
clients to speak directly to specific clients (a private message, just
teammates, etc). Also unimplemented, there are hooks for the server to
maintain a blacklist, so annoying chatters can play, but their VoIP
packets will be dropped without the server rebroadcasting them to other
clients.
The client requires an OpenAL with ALC_EXT_capture support (which is any
OpenAL 1.1 implementation...which is most of them, now)...all voice
packets are sent to all players that are listening. This isn't really a
design flaw so much as unimplemented code...the client needs a means to
decide who to send voice to, but that's largely a question of UI and
some global variables.
All my VoIP changes are wrapped in #if USE_VOIP, but it should be
harmless to build everywhere without the #ifdefs, since it doesn't break
network compat and you have to enable the feature with cvars.
This work involves patches to a few bits of the engine. The first adds
"streams" to the sound interface, so S_RawSamples() can specify which
stream the new sound data goes with. The usual uses of S_RawSamples()
use stream zero, then each player's voip data is stream 1 through n.
Even though the primary intention is to offload the management and
mixing of various VoIP streams to the audio layer, this could be useful
for other mods, perhaps, with a little more cleanup.
The rest of the patches are the VoIP-specific bits.
To use:
- Install libspeex from speex.org
- Patch your client. Build with USE_VOIP=1.
- Hook up a microphone.
- Add this to your startup script (change Q to your liking)
    bind q "+voiprecord"
- Start the client with these cvars:
    +set s_useOpenAL 1 +set voip 1
- Patch your server. Build with USE_VOIP=1.
- Start the server with this cvar:
    +set sv_voip 1
- Connect some patched clients to the patched server.
- While playing, hold down 'Q' and speak into your microphone.
- Server rebroadcasts your voice to all clients.
- Patched clients hear you. Hopefully.
cvar notes:
- s_alCapture 1 tells the audio layer to open an OpenAL capture device.
Without this set on sound startup, you'll never get bits from the
microphone.
- voip 1 enables VoIP support on the client. Without this set, we'll
just drop any incoming VoIP data and refuse to record audio data for
sending.
- cl_voipGainDuringCapture is the volume of audio coming out of your
speakers while you are recording sound for transmission. This is a
floating point value between 0.0 and 1.0, zero being silence and one
being no reduction in volume. This prevents audio feedback and echo and
such, but if you're listening in headphones that your mic won't pick up,
you don't need to turn down the gain. Default is 0.2 (20% of normal volume).
- cl_voipSend is set to 1 by the game when the player wants to record
and send VoIP packets. This is not a command line thing...the cvar is
toggled with a keybind, so you only record when explicitly holding down
a specified key.
- sv_voip 1 tells the server to accept and rebroadcast voip packets.
Without this, all VoIP packets sent to the server are dropped, so no one
hears anything from any client. This cvar will make the server report
voip support in the server browser query.
- "+voiprecord" is the action you should bind to a key to record.
- "voip ignore <playernum>" is a console command that tells the client
to drop any VoIP packets that arrive from a specific player number. It
will also inform the server of this with a reliable command, so it won't
even send the packets until further notice.
- "voip unignore <playernum>" is the opposite of "voip ignore".
- "voip muteall" is a console command that is the rough equivalent of
"voip ignore" for each player in the game, except when you unmute, your
previous ignores of specific players were not lost.
- "voip unmuteall" is the opposite of "voip muteall".
Some of this code is not as clean as I'd like, and there's a lot of
hardcoding and a few shortcuts. Cleaning those up would be wise. I would
recommend against committing this patch to ioq3's repository (or any
project based on ioq3) until there has been some review and improvements.
Other things to be done (or at least, things worth doing):
Client:
- Add UI that shows a volume meter while recording, based on the value
of clc.voipPower...this value changes every frame based on audio input,
so it can be used to show how well the game is "hearing" you. 1.0f is
loud, 0.0f is silent. Reuse the cgame lagometer code?
- Update server browser to note which servers are VoIP compatible (look
for voip=1 in the infoResponse packet).
- Decide if a VoIP packet is too old to be worth playing when it arrives
, and if so, just drop it. We handle sequencing and ordering, this is
just a question of latency.
- Fill in the audio layer's recording code for other platforms (or are
we only OpenAL
now?).
- Fill in the mixer code for S_Base_RawSamples() where stream != 0 (or
are we only OpenAL now?).
- Clean up speex dependency (statically link it? Include it in the
project?).
- Team-only chat, groups, friends, etc...right now everything goes to
everyone by default, and while the protocol allows for culling the
recipient list of a given VoIP packet, there's no code or ui to actually
do the culling at the moment.
- Have a UI to speak only to the person currently in your crosshairs
("hey, turn around.")
Server:
- Allow users to be blacklisted by the admin, so if they send a voip
packet, you just drop it without rebroadcast.
- Do some sanity checking on the speex data before rebroadcast?
Both:
- Look at all my FIXMEs.
- Voice positioning...right now there's no in-world position for VoIP,
but it'd be interesting if you could only hear people near you (and the
server regulated this by choosing a cutoff distance and refusing to send
you packets from people that are past it), and the client spatialized it
so the voice came from the same place as the speaker in-world. UT2004
has this as an option, but beyond the cool factor or a specific mod that
requires that functionality, I don't see it as valuable.
As you can see, there's still a _lot_ to be done to make this robust,
and a lot of it depends on small UI mods. I just wanted to put down a
framework for others to build on here.
Opinions?
--ryan.

Eventually, we ended up with this bugzilla entry, commit 1347 and commit 1348. Eventually, it will reach some pre-built binaries and a quake 3 server near you.