Mumble: Reduce number of AudioInput callbacks

[fedetft]

When using Mumble on Linux with echo cancellation, it sometimes occupies around 80% CPU globally. It doesn't happen every time, and it seems to solve itself after some time (more on this later).

What do I mean globally? I mean that while Mumble itself uses around 30% CPU, it makes pulseaudio occupy around 50% CPU.

Compare with recording from the microphone using Audacity, where audacity occupies 20% CPU, and pulsaudio just 4%.

The fact that Mumble makes pulseaudio occupy more CPU made me suspicious, and armed with my new knowledge of how AudioInput works, I suspected a callback rate issue.

So, attached you'll find a patch to profile how many callacks per second pulseaudio is doing to addMic() and addEcho(). It's not meant to end up in Mumble permanently, consider it a testing hack.

The result is that while the addMic() callback is called between 180 and 200 times per second (that amounts to around 5ms of audio at a time), the addEcho() is sometimes called up to 2300 times a second. And that is Too much™. So much interprocess communication between pulseaudio and Mumble is just a waste of resources.

Apparently this high rate occurs only sometimes and only when mumble is just started, after that it slowly reduces to around 260 callbacks per second. Don't know why, maybe pulseaudio has a rate limiter of some sort?

In any case, I'd be very surprised if the pulseaudio API didn't have a way to tell "Dear pulseaudio, could you please wait until you have X audio samples before firing a callback?"

If we make X equal to the amount of samples in 10ms at the correct sample frequency, and do so for both microphone and echo, we could minimize the number of callbacks, CPU use, power consumption (people use Mumble also in laptops when running from battery), and disruptions to the OS scheduler which may be good while gaming.

Also, we could enable the echo canceller by default if it's optimized, which will improve user experience.

NOTE: I only tried on Linux with pulseaudio, can someone run the patch on Windows and see if a similar issue occurs also there?
callabck_profiling.txt

[toby63]

So to clarify:
What do you think causes this problem:

• Mumble
  or
• Pulseaudio
  ?

In any case, I'd be very surprised if pulseaudio didn't have a way to tell it "Dear pulseaudio, could you please wait until you have X audio samples before firing a callback?"

I guess you mean "mumble" instead of "pulseaudio" in the first mention?
So this would be the way to a solution?

[fedetft]

The way mumble's pulseaudio driver registers callbacks.

I guess the issue is somewhere in here https://github.com/mumble-voip/mumble/blob/master/src/mumble/PulseAudio.cpp

And I do mean pulseaudio's API, rather than the pulseaudio daemon.

[toby63]

@Krzmbrzl Is maybe a bug though :thinking:

[Krzmbrzl]

Yeah - probably true :)

[fedetft]

Apparently this bug is at least partially a duplicate of this one https://github.com/mumble-voip/mumble/issues/1092 and appears to date back to 2013.

[itsrachelfish]

I always wondered why mumble used so much CPU. I hope this gets fixed!