Implement voice chat (VoIP)

[LegendaryGuard]

Closes #61

With DP_RM_VOIP extension, use one of my branches to experiment with QuakeC: https://github.com/LegendaryGuard/darkplaces/tree/LegendaryGuard/DP_RM_VOIP
you're free to do whatever there.

That implementation came from DarkPlaces RM.
This feature can be tested on the latest version of Rexuiz, just bind the key of the voice chat feature, press and hold the binded key, and speak, everyone will hear the voice and noises of who enables it if the microphone is on.
Uses OPUS.

Added cvars:

• sv_voip: Enable voip support in server
• sv_voip_echo: Echo mode for VOIP, for testing purpose
• sv_voip_force: Force VOIP between players, even if QuakeC didn't want it

• voipvolume: volume of voip
• snd_input_boost: Audio input boost
• snd_input_boost_auto: Audio input boost

Added commmands:

• snd_list_input_devices: list input audio devices
• snd_set_input_device: set input audio device
• snd_echo_start: start microphone echo test
• snd_echo_stop: stop microphone echo test

To bind keys:

• +snd_voip_talk: start voip
• -snd_voip_talk: stop voip

NOTE: Feel free to tweak the code and contribute, you can open other new PR as copy of that if I'm not active.
Anyone is free to copy the code, it's GPL-licensed.

P.D. If the owners/maintainers don't agree, feel free to fork my branch repository and do experiments.

[hemebond]

What is the workflow/usage around voipgroup? Currently it defaults to zero, which, by default, means no one hears voip unless sv_voip_force is enabled on the server.

[LegendaryGuard]

@hemebond I overwritten the commit.
Also, is squash merge allowed here?
Just asking, because I think after that feature is merged, we could trace better the source of an issue that could happen.

[LegendaryGuard]

What is the workflow/usage around voipgroup? Currently it defaults to zero, which, by default, means no one hears voip unless sv_voip_force is enabled on the server.

Not sure. I believe "voipgroup" and "voiplistengroup" should mean only can talk and listen in such group of people while others can't talk and listen in that same one.

Imagine playing team gamemodes like Team Deathmatch, Capture The Flag, Prop Hunt, Trouble in Terrorist Town, ...
You would wanna talk to your team to plan your strategies in the matches.

Also in normal gamemodes, while being a spectator and you don't play, you would wanna talk with the spectators without disturbing the players.

[hemebond]

@hemebond I overwritten the commit. Also, is squash merge allowed here? Just asking, because I think after that feature is merged, we could trace better the source of an issue that could happen.

When it's merged into main/master your PR should be squash merged, yes. So you can just add commits to your PR.

[hemebond]

What is the workflow/usage around voipgroup? Currently it defaults to zero, which, by default, means no one hears voip unless sv_voip_force is enabled on the server.

Not sure. I believe "voipgroup" and "voiplistengroup" should mean only can talk and listen in such group of people while others can't talk and listen in that same one.

Imagine playing team gamemodes like Team Deathmatch, Capture The Flag, Prop Hunt, Trouble in Terrorist Town, ... You would wanna talk to your team to plan your strategies in the matches.

Also in normal gamemodes, while being a spectator and you don't play, you would wanna talk with the spectators without disturbing the players.

So voipgroup 0 means no voip, unless sv_voip_force is enabled. Otherwise modders use voipgroup and voiplistengroup fields to group players allowing them to talk to each other. Sounds good.

I'm having a bit of trouble getting it to work reliably. With player 1 (listen host) sending voip (snd_voip_force enabled), player 2 console gets a constant stream of:

Schedule voip sfx remove
VOIP sound buffer truncated
Schedule voip sfx remove
VOIP sound buffer truncated
VOIP sound samples missed (too far in future)

and no sound. Not sure how I got it to work previously. snd_echo_start works okay.

[hemebond]

The new QuakeC fields and functions should probably also be added to the dpdefs files; otherwise modders won't know about them.

EDIT: I've created #306 as a follow up task for myself to add the defs after I've tested them.

[LegendaryGuard]

The new QuakeC fields and functions should probably also be added to the dpdefs files; otherwise modders won't know about them.

EDIT: I've created #306 as a follow up task for myself to add the defs after I've tested them.

@hemebond
Done at e443c08. Tell me if something is missing or wrong. Thanks!

[Cloudwalk9]

Not gonna merge this yet because we want to track FTEQW compatibility as closely as possible. We want to make sure this at least won't complicate FTEQW compatibility later. So consider this pending or "will merge what ever it takes eventually". Definitely not saying no to the Opus capture plumbing at least.

[Cloudwalk9]

On closer review: absolutely not. I'll merge everything except the extension. This creates a parallel mini protocol on raw UDP with the magic bytes "VOIP" and yells it directly into the bowels of the audio subsystem. Demos won't be able to record voice, it doesn't benefit from the same serialization and debugging ability as the protocol layer and its own bounds and sanity checks. It's not something I'm comfortable upstreaming.

FTE uses a pair of netmessages, and so does Source and GoldSrc. I'd rather we go that route than trying to sidestep the Quake protocol state machine.

Yeah it's insane to mint a new protocol number every new feature we add. So FTE pext is something we want to consider eventually. But this is a recipe for some fun extra bugs from edge cases because it doesn't go through an existing battle tested path that everything else does.

[LegendaryGuard]

@Cloudwalk9
I didn't know that was sensitive.

I just did that at 5b91d28 regarding your reply, anything else?