Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I've noticed that Mumble consumes relatively high CPU resources, running at a
constant 12-21% on a C2D even when idle. I can't really be certain if this is
normal, but assuming the standard behaviour is poll server, get packets,
sleep, repeat, then it does seem overly taxing.
As Mumble is supposed to be a "background" program it shouldn't be competing
for resources with the game.
12-21% sounds very high to me. A bit load even when Idle (or even when not
being connected to server) is to be expected. Mumble constantly processes the
audio data coming from the microphone while running to adjust it's noise, echo
and automatic gain control filters. Depending on your system settings this
might also imply resampling the audio from the frequency range provided by
your hardware to the one used by mumble internally (which is 48kHz, if you can
configure your out- and input devices to use these).
On my C2D 6750 (2x2,6Ghz) mumble uses between 0-8% CPU during normal operation
which imho is a reasonable value for the tasks it performs (even though it
could be improved).
I guess the range is closer to 8-17% after factoring in system processes (i.e.
usage is 12-21% with Mumble, 0-4% when I close Mumble), but it rarely drops
I spend a lot of time idling while muted, so I would think Mumble would save
itself the trouble and just stop polling the mic in that case. On your advice
I just switched my default recording format from 44100Hz to 48000Hz (16bit,
stereo), haven't seen a difference, but if it avoids resampling I'll leave it
there. Though I'm a bit curious as to why Mumble samples at 48Khz when it's
primarily dealing with human voice?
I'll have to test a bit more, but I think setting the core affinity to a
single core seems to help. Does Mumble make much use of multithreading?
Hmm, yeah, I looked at my CPU usage and mumble was at a nice 20%. That seemed
a bit insane to me so I googled this thread! Pretty much every last % of that
seems to be in echo cancellation (with pulse audio selected). I disabled echo
and the CPU% dropped down to much lower numbers. Mumble really shouldn't use
that much CPU when idle.
Echo cancellation is a CPU intensive task. I guess that if both you and your
party are not talking the CPU usage will be reduced.
Because of certain circumstances i have to use Mumble on my notebook running
But the CPU usage (even idle) is unaccaptable for me:
This shortens the runtime of my battery, increases noise and heat,
So I took a look on the well structured but completely uncommented source
(SHAME, not interested in others understanding their code? )
After adding few lines here and there the CPU usage (idle) dropped to
Thats 90% idle (up to 50% talking) without quality or latency loss . My
personal opinion is that it is even better than before.
I can even switch between my power saving option and the default one without
Its really a shame. That blah blah for high end gamer pc blah blah Quality
blah blah is a weak pretext.
Bad for environment too. Using up to 10W on each machine its used on for
You could tell us what you did to fix the problem, because I'm not using the
client on Linux and can't really debug that.
i am glad you are asking, because the cpu usage is not really a bug.
I simply added a real idle mode (for sending and receiving seperately) while
preserving the preprocessing settings. So there is no full up/down stream even
when nothing happens.
A "real" bug is perhaps the sudden cut off when using push-to-talk, so i added
a tolerace there. I guess it is ignoring the latency or maybe it my slower
notebook hardware. Now it works fine.
Its a quick and dirt fix because there are no commemts and i dont have the
time to read through all the code and try to figure out what it is doing. (+
compile difficulties with added class functions)
I have made a Bug report for this incident
But unfortunately it seems no one has an interest any more, to make an effort
in develop mumble any further.