#868 High cpu usage when nothing happens

Mumble (544)

I am running Gentoo Linux Kernel 3.2.1-gentoo-r2 x86_64 AMD A8-3500M APU with mumble 1.2.3-r2 + pulseaudio
and just noticed a cpu usage of 15 - 20% when it should be idle, even without echo cancellation it's about 10%.

After searching for mumble+high+cpu i came over this forums post:

"Because of certain circumstances i have to use Mumble on my notebook running Ubuntu. But the CPU usage (even idle) is unaccaptable for me: ~10% mumble ~10% pulseaudio This shortens the runtime of my battery, increases noise and heat, unnacessarily! 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 1% mumble 1% pulseaudio 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 restarting mumble. 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 idling?"
and this:;
"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)"

After realizing that this behavior did not change since over one year i thought now it's time to do something!


  • Benjamin Jemlich

    Feel free to ask the person who wrote that forum post for his patch and get it into a state that can be merged. I have no way to reproduce the problem and can't really test any patches modifying the pulseaudio code...

  • Jaroni

    Jaroni - 2012-07-01

    I have the same problem on archlinux (32bit) too, with mumble 1.2.3a. High CPU load even though I use push to talk and when noone else is on the server. (And echo cancellation is off.) Mumble would be pretty usable without this, but this CPU drain is a serious issue unfortunately.

  • andromeda

    andromeda - 2012-07-01

    I have ask daishi99 to make his patch available but he has no interests or does not understand my question.

    Unfortunately i also don't know why this has not been patched six month later. Sadly i have no experience in C, but it does not seem to be that hard to implement a "real idle mode".

    My current version of pulseaudio has a load of 3% if idle, if mumble logged in (idle) it's 20%!

    If i had a project like this, my conception of quality would consider this behavior as not acceptable.

  • andromeda

    andromeda - 2012-10-10

    We have the year 2012 and time comes forth and we have October. The weeks passes by, ...the months passes by and the years passes by ... and we have mumble 1.2.3 as before,
    All stays the same.
    Except my pulseaudio is now version 2.1 and my mumble has now a 35% to 45 % cpu usage. In IDLE!

    "I have no way to reproduce the problem
    and can't really test any patches modifying the pulseaudio code..."

    I have an idea specially for you: Grab a linux distro DVD, boot it and make a dual boot install of ubuntu or something else with pulseaudio on your machine and watch what it will do.

  • Nicos Gollan

    Nicos Gollan - 2012-10-11

    For the record:

    Running things with Pulseaudio, I see a continuous load around 5% from the mumble client when idle, and around 8% with continuous local feedback. In the audio input settings, that value spikes to maybe 15–20% which is likely due to the VAD indicator redraw and some other "goodies" in there. (Debian's -348 client)

    If you are observing extremely high CPU use, please check:

    • if things get better without pulseaudio, and
    • if you or your distribution made some non-standard settings like enabling a high-quality resampler.
  • andromeda

    andromeda - 2012-10-11

    For the record:
    Please note that the fix for this behaviour is >>>> to spend mumble a real idle mode <<<< for the pulseaudio module.

  • andromeda

    andromeda - 2013-07-12

    With Mumble 1.2.4 The CPU usage is about 15% - 18% for Mumble and 20% - 23% for Pulseaudio.

    I know even to have an real idle mode in mumble would not really fix this but make things at least better.

    I really don't know what you think when you see those facts...

    But, do you truly think the solution for this is to just buy a better CPU?

  • Colin S.

    Colin S. - 2013-07-20

    I too have problems with high CPU usage with PulseAudio. I like to idle a lot, and I don't think mumble should eat CPU when nothing is happening. My suggested fix is to stop the audio input processing whenever the user is Self-Muted. The best way to do this, in my opinion, is to mute ("cork") the audio input stream.

    I have added a Qt signal, corkStream(), which is emitted by MainWindow.cpp whenever the user toggles their Self-Mute state. The PulseAudioSystem has a slot for this signal and acts accordingly whenever it is received. Since it's a Qt signal, other sound backends could easily be modified to do the same thing.

    Enclosed is a patch against master. The one problem with this patch is that it doesn't correctly set the mute state when mumble starts up. I've been using it for quite awhile, though, and it seems to help. If there is interest from the developers, I can try to fix the startup state problem.

  • Colin S.

    Colin S. - 2013-08-05

    I am going to clean this up a bit, fix an audio setup wizard bug that the patch introduces, and resubmit this as a github pull instead.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks