hpr-knowledge-base/hpr_transcripts/hpr1181.txt

Episode: 1181
Title: HPR1181: Mumble Audio Issues
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1181/hpr1181.mp3
Transcribed: 2025-10-17 21:06:58

---

Greetings, Delan here again.
After getting feedback on the last mumble episode, I thought it might be worthwhile to take
a few minutes to talk about some of the specific audio issues people encountered and what
can be done about them.
There seem to be four main issues that people typically experience, and we're going to
be working in the audio input setting section with advanced options toggled on.
The checkbox for the advanced options is located in the lower left corner of the configured
screen.
Going through the audio wizard does many of these things automatically, but if you're
going to try and fine tune your audio, I think it's simpler to do it this way.
The first and most common issue is static or peeking, particularly when speaking loudly,
and it sounds something like this.
Okay, with luck, this should be badly overdriven.
The first step in addressing this is to decrease your amplification in your mumble audio
settings.
If you have decreased the amplification within mumble to 1.0, it's lowest setting, but
you're still experiencing peeking, then you'll need to adjust your microphone input level
in your sound card mixer settings.
The second problem is quiet audio, which I suggest handling in the opposite direction.
First, adjust your mixer settings and raise your mic level as high as you're comfortable
with, and then try the amplification settings within mumble.
The third is distorted or warbling audio, which might sound something like this.
And this should be what it sounds like when noise suppression is too high.
This is generally caused by the noise suppression settings.
Noise suppression attempts to act as a filter to remove background noise, but when it is set
too high, it can distort your audio and make it sound almost watery for lack of a better
term.
Mumble defaults to negative 30 decibels, but I find that negative 15 to negative 20 tends
to offer a better balance between distortion and background filtering.
Results can vary pretty wildly here, and it all depends on the noise level in your environment
and the microphone you're using.
The fourth is choppy audio, like this.
This is typically a result of a poor internet connection rather than audio settings.
The first thing to try is to turn off the quality of service settings in mumble, which
are located in the network section.
It's not likely that this will help.
It seems to be more affixed for when your client is being repeatedly dropped by the server,
but turning it off will help eliminate one possible source of trouble.
Just try adjusting your audio per packet in quality settings, found in the advanced audio
input section.
I recommend increasing your audio per packet settings, and then decreasing your quality
settings.
But be aware that once you drop below about 45 kilobits per second, you'll be using
speaks rather than kelt as your audio codec.
Mumble will tell you which codec you're trying to use under the audio per packet slider,
so it will let you know once you've crossed that threshold.
I should also note here that mumble 1.2.3 is starting to ship without speaks support
in some distros, and once 1.2.4 drops, the preferred codec will be opus.
If you run into an issue where people can't hear one another, this is almost certainly
the cause.
The answer for the time being is to try to get everyone on kelt.
Yes, this is a bit of a pain in the ass.
As a year ago, speaks was the codec all installations had in common.
And yes, we're probably going to go through this rigmarole again once 1.2.4 comes out,
at least until everyone is fully on board with opus.
And in the last episode I did about mumble, I mentioned that you can turn on loopback either
locally or from the server in order to hear your own audio.
This works well, but it requires you to listen to your voice as you're speaking, which
can be a little confusing.
However, there is another option which might work better for you.
Evebot was written to capture audio from one channel and then transmitted into another
channel after a delay, mainly used during game tournaments to match team communications
with the delayed video feed.
However, you can also use it as a delayed loopback for an audio testing channel.
When you give the bot the command to connect, tell it to use the same channel in the eavesdrop
and relay options.
It's smart enough to avoid going into a mimic spawning loop.
I like to set the delay to 10 seconds, as a shorter delay doesn't give me enough time
to say enough to get a decent idea of what the audio is actually sounding like.
You can find Evebot at Freemaster, f-r-y-m-a-s-t-e-r dot 1-2-7-001 dot org slash mumble.
You have been listening to Hacker Public Radio, or Tacker Public Radio does our.
We are a community podcast network that releases shows every weekday on day through Friday.
Today's show, like all our shows, was contributed by a HPR listener like yourself.
If you ever consider recording a podcast, then visit our website to find out how easy
it really is.
Hacker Public Radio was founded by the Digital Dog Pound and the Infonomicom Computer Club.
HPR is funded by the binary revolution at binref.com, all binref projects are proudly sponsored
by Lunar Pages.
For shared hosting to custom private clouds, go to LunarPages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative commons, attribution,
share a line, free those own license.