Mumble is a leading open source VoIP solution for social gamers. Our primary design goal is that you should be able to talk as if you were in the same room; this means high quality compression, noise filtration, echo cancellation and no delay. Reproducing human speech without any of the artifacts associated with recording and playback equipment is hard, and doing so without any delay at all is even harder. Judging on the feedback we get, we have succeeded.
Mumble also has an in-game overlay; this works in full screen games, and shows you a graphical representation of who is in the same channel (virtual room) as you, and who is talking right now. We also have positional audio for supported games; the voice of your friends will sound like it comes from the same direction their in-game avatar is.
Why and how did you get started?
I was tired of listening to background noise from the people I was gaming with, and the high latency meant communication was usually walkie-talkie style. It doesn’t really help to hear your friend yell “watch out” just after you die.
At the same time, I had a videochat application I’d developed for playing tabletop RPG with my friends, so I knew that with proper signal processing, you can get very high quality, natural audio. Splitting out the audio part of that into a separate application was the next logical step and, according to sourceforge, this was done 2005-08-31.
Who is the software’s intended audience?
Gamers; both overly chatty and social people who like to talk and have fun while playing video games together, and also fast and efficient command structures for more hardcore gaming.
What are a couple of notable examples of how people are using your software?
Most of our users are gamers, using it to connect with their friends to do gaming. However, people also use it to life-size simulators, podcast, do interviews, classroom education, research collaboration and development; none of which we originally intended or thought of when we wrote this. It seems once you provide high quality basic functionality, people are happy to adapt.
There are now a lot of commercial hosters, some of which service thousands of simultaneous users from a single machine.
What are the system requirements for your software, and what do people need to know about getting it set up and running?
For the client a modern PC and a microphone. Officially, we support Windows, OSX and Linux, but people have used it successfully on BSDs and even on small embedded devices. On the server side we require good connectivity and network hardware that is able to cope with our high packet rate, but murmur (which is what the server component is called) scales well to thousands of simultaneous users. Administration of the server is not as easy as we’d like it to be, but this is improved greatly in 1.2.0 and there are also several 3rd party interfaces for controlling the server (which is fully programmable).
What gave you an indication that your project was becoming successful?
The first indication was third-party patches and our first few commercial hosters, and being nominated for community choice awards also helped. The biggest indication was still to be contacted by several different companies that wanted to buy the project Â
What has been your biggest surprise?
Being contacted by venture capital.
What has been your biggest challenge?
Supporting low level interfaces on three relatively different platforms, each with their own set of quirks. While there are audio abstractions for all platforms, we need to get as close to the hardware as possible to push latency low, which means native support for multiple generations of audio APIs on each platform. Another challenge is the overlay; while it is relatively straightforward to create an overlay that works with most games, it’s rather hard to create one that works with other overlays as well.
Why do you think your project has been so well received?
We have superior voice quality and offer a lot of features competing programs don’t have, all in a open source package. We do regular releases, and actively invite our users to help and comment on our development process.
What advice would you give to a project that’s just starting out?
Do something you have a passion for; if you have only a casual interest in the subject, you will burn out pretty fast. Make sure you are an active user of your own software. Be aware that you won’t get thousands of users immediately; most people are adverse to change and will not start using your software until there is peer pressure to try it. Don’t be disheartened by bug reports, they mean someone cared enough about your project to file them, and it means they want them fixed so they can continue using it.
Where do you see your project going?
I see it going places I don’t foresee; one of our most requested features for 1.2.0 was to replace all mentions of “player” in the GUI with “user”, so it would more natural to use in other environments than gaming. I also see parts of Mumble going into commercial projects; I chose the BSD license so that it can be used in other projects, open or closed.
What’s on your project wish list?
First, in-game video; let your friends see you as well as hear you. The basic proof of concept has been done for some time, there’s just a lot of practical problems that need to be solved.
Next, more game plugins. Right now, these require us to track the game process, which breaks whenever the game updates. However, a lot of open source games explicitly support Mumble, giving us all the data we need through our Link system, and it seems a few commercial games might start doing so as well.
More short term, we have a lot of requests on our feature request tracker that we haven’t gotten around to yet. It pains me a bit that some of them just sit there, but there just hasn’t been enough time to implement them all, and we have to prioritize.
What are you most proud of?
Our audio engine, which produces low-latency audio on a number of platforms.
The number of users we have that use Mumble each day. That people choose Mumble when there are quite a few alternatives really is a clear indicator that we’re doing something better
The ever increasing number of third party tools for controlling the server, and the number of skins for the client.
If you could change something about the project, what would it be?
With the upcoming 1.2.0, we’re changing the protocol, which unfortuantely breaks compatibility with existing clients and servers. I really wish we had done so much earlier, before we had so many users.
How do you coordinate the project?
Assignments are usually handled on IRC, and goes in the form “I want to
How many hours a month do you and/or your team devote to the project?
More than I’m comfortable admitting.
What is your development environment like?
slicer: Most of my server development is done on a Dell PowerEdge running RHEL5 with quite a few custom packages. Most of the client development is done on a Dell XPS M1730 with Windows 7 (cl, Textpad and cmd) and Ubuntu (g++, joe and bash). All sourcecode is maintained in git.
mkrautz: Most of my development happens in Mac OS X, running on my white MacBook, but occasionally I’ll do some work on Windows (where I use Windows 7), or on Linux (Ubuntu). I like to treat OS X as a ‘shiny’ version of Unix, so I usually have tons of terminals open with many tabs in each. Text editing is done with MacVim. As far as compilers and debuggers go, I simply use the Xcode-provided versions of gcc and gdb.Â
|Version / Date||Milestone|
|0.9.0 (Sep 05)||This was the first release that had proper grouping of users into channels, with a permission system. While voice alone had always worked, this version had most of the features our competitors did.|
|0.9.1 (Oct 05)||First version with our ingame overlay.|
|1.0.0 (Jul 07)||This was the end our our alphas and betas; it was the first release to recieve proper polishing, including updated translations and even a small testing period prior to the release.|
|1.1.0 (Oct 07)||From this version forward, all communication has mandatory encryption.|
|1.2.0 (Nov/Dec 09)||New audio codec (CELT) and new extensible protocol.|
|2.0.0 (?)||Multiuser videochat.|
How can others contribute?
We’re always looking for more people. Codewise, we welcome patches, and all current developers started out by submitting a few patches to the project. We are desperate for documentation writers, but I think that’s common for opensource projects these days. We also have a need for more translators; we have quite a few quality translations already, but could use a few more. This is just the tip of the iceberg though; our current list of requests is far longer than we can handle, so we welcome any help we can get
Project name: Mumble
Date founded: August, 2005
Project page: http://mumble.sourceforge.net/
Occupation: Right now; PhD Student
Location: Trondheim, Norway
Education: Almost a PhD
Location: Esbjerg, Denmark
Why did you place the project on SourceForge.net?
Everyone else seemed to do so, and you offered the services we needed. SourceForge was “the” place to be if you hosted an open source project, so I just went with the flow.
How has SourceForge.net helped your project succeed?
In addition to the direct services offered, being hosted on sourceforge means you get automatically indexed by a lot of software sites; our news and file releases are automatically propagated, and the “.sourceforge.net” ending gives a certian legitimacy to the project as “open source”. You’re a recognized name, and we’re leeching on your fame.
The number one benefit of using SourceForge.net is:
That we can focus on the code, and not worry about the support infrastructure.