High CPU Usage

  • Anthony

    Anthony - 2010-01-01

    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.

  • Stefan H.

    Stefan H. - 2010-01-01

    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).

  • Anthony

    Anthony - 2010-01-02

    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
    below that.

    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?

  • Anonymous - 2011-01-04

    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.

  • Mike

    Mike - 2011-01-07

    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.

  • Jones99

    Jones99 - 2012-01-26

    Because of certain circumstances i have to use Mumble on my notebook running
    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,
    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

  • Benjamin Jemlich

    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.

  • Jones99

    Jones99 - 2012-01-27

    hello pcgod,
    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)