Voice system integration - mumble/murmur

[Licho]

I would like to go ahead with voice system integration (once I finish some stuff for CA).

Mumble/murmur (http://mumble.sourceforge.net/) is open source multiplatform voice comm software with very nice specs and features (like OpenGL and DirectX overlay display).

It also provides "DBus" interface both to client (Mumble) and server (Murmur) through dll calls.


I imagine integration working in this way:
- game host optionally starts murmur server and through DBus creates channels for each team and for spectators
- game client optionally uses DBus to connect locally installed mumble to host's server
- game host makes sure people cannot switch channels until they are dead -> moved to specs


Murmur control can be implented either in spring itself (reads script.txt with desired murmur port and mumble player names corresponding to player IDs.

Lobbies would need to read some extra messages (with host murmur port) and determine mumble player name and send it back to host. They would also need to tell local mumble to connect to target murmur after game is started ..

Or it can be implemented all within lobby clients.. Lobbies can easilly know when player died too (in SVN spring there is CAutohostInterface which provides this and more over network UDP loopback)

Lobby client could start or just use existing running murmur and players could be connected to it even during team setup.

Personally I think it should all be implemented within lobbies.

I can provide either
- sample implementation for murmur control into springie (should be easy to convert to C++ or any other language)
- instructions how to implement mumble control for clients (would be very simple, DBus interface for mumble currently have one command - connect :)

Or
- managed executables or dll (or COM) for integration with both client and host integration (yes Im too lazy to do unmanaged libraries in C++)


What do you think?

[MR.D]

Don't furget the "MUTE" button :D

[Satirik]

don't like the idea ... we should help people to join the ts server (or whatever soft you want) and maybe add a button to lobbies that join the good channel ...

[Tobi]

Should not be in Spring itself IMHO. I'll be happy to help with adding hooks or anything (provided I have the time) so it can be easily added as external module or something, but I think it is currently not wise to integrate it directly into the Spring codebase.

(same address space, so memory corruption in either part of the program could crash the entire thing, maybe sound stuff can be done better with another FPU control word, etc.)

[Licho]

Well murmur and mumble IS standalone software Satirik..

Its separate software so it would be as you say .. button to join correct channel..

But you need (or should have) some host side support to make sure people are in right teams and cannot "cheat" etc..

And yes mumble has mute button :)

Its just like TS2 or ventrilo .. just better codecs,nice features and open source

[LordMatt]

Well, how would this work for linux people? I think spring uses OSS, which would tie up the sound card and prevent someone from using a voice chat program at the same time.

[Licho]

You can test it .. just download mumble and try if it works together with spring.

[rcdraco]

I personally have seen too many issues with Microphones, and the only time people use it is if it is implemented, but then the people that use it are little kids that have a slow connection and a crappy pc, that's just my 2 cents, maybe push more on the TeamSpeak Server, But I don't see any reason to have microphones implemented into spring, it would just get overused, and standard chat would become obsolete.

Instead of using points and ally chat, people would end up saying, "Go up to that hill" , which would lead to further confusion, and probably end up losing players who think some of our pros are "newbs" because of communication problems.

[Licho]

Well im used to intensive team games like NS where voice chat works and is used well and integral part of the game.
Voice chat is fater than typing and more people react to it (people often miss written chat). It can create more intense atmosphere too.

It woudlnt really be "integrated" think of it as about intelligent automatic setup of channels for spring.

[trepan]

Spring uses OpenAL in linux, which can be configured to use
ALSA instead of OSS (check your /etc/openalrc or ~/.openalrc).
I have not had any problems running multiple sound clients at
the same time.

That being said, I agree with Tobi

[AF]

There're a lot of people who've expressed opinions that mumble is just crap.

Ontop of that if you want to go ahead with ti then fien but try not to offload much onto us lobby developers and keep everything as simple as possible, and use conventions we already use, no going off into using some transport mechanism that requires an entirely new codebase to use or a protocol thats completely different (e.g. xml).

[Licho]

Well I wont go ahead if there is no interest. So far it seems that nobody is really interested..

There is no point to implement unpopular feature..

AF who said it's crap and why?
Im using it it works perfectly and has much better voice activation and codecs than TS2 or ventrilo..

[AF]

I wouldnt be a very good person if I started naming names.

But what work would you have to do outside of springie anyway?

[Licho]

Clients need to tell local mumbles (if running) to connect to server and forward mumble id to server.

Thats all clients need to do I think.

[Relative]

I wouldnt be a very good person if I started naming names.

But what work would you have to do outside of springie anyway?

CA

[Neddie]

I have to say, TeamTalk pretty much overwhelms the alternatives.

[LordMatt]

Licho I think its a good idea, I just wondered if it would work for me or not. Is there one of these programs that can use ALSA instead of OSS though? I know teamspeak only works with OSS (microphone doesn't work with aoss).

Edit: Duh, I should have known spring was using ALSA as I play music while playing all the time.

[Relative]

Licho I think its a good idea, I just wondered if it would work for me or not. Is there one of these programs that can use ALSA instead of OSS though? I know teamspeak only works with OSS (microphone doesn't work with aoss).

Edit: Duh, I should have known spring was using ALSA as I play music while playing all the time.

Mumble uses ALSA.

[cong06]

Well I wont go ahead if there is no interest. So far it seems that nobody is really interested..

well, I mean, it sounds cool. I'm at least partially interested. Not that I can really contribute anything however. or that it's worthwhile to make a whole new feature just for me...

[carbon]

Personally, I think it would be a great idea to implement voice chat in the way Licho has suggested. I can recall several games a friend and I played by collaborating and coordinating our attacks while in the same room. We were like a well oiled machine and didn't have to bother ourselves with typing out lengthy attack plans/requests. I think it would add a new level of play to the current state of Spring.

If I understand his proposal correctly, a command line-ish mumble/murmur client and host would be included in the Spring install, the host's Spring Lobby would automatically setup the server and designated team rooms and send relevant information to the clients' Spring Lobby for an auto-join like action (all defined by running mumble/murmur with command line switches and parameters); thereby providing a seamless and fully integrated voice chat experience without really having to integrate heaps of code into the engine to make this possible.

It's also great because if someone doesn't want to use voice chat then they can just forgo setting up the server or disable it in their Spring Lobby which would treat it sort of like a plugin. I seems like a great workaround that wouldn't add any overhead or bloatware if you will.

I assume the appropriate hooks etc. would be have to be added by the Spring devs for control of functions such as muting etc. within Spring. Also, a great deal of cooperation would be needed from the lobby devs for this intelligent auto-setup of the voice chat server and its rooms. Or are you proposing to do all of the above work Licho?