starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

Mumble increases "Microphone power" over time (Pipewire) #2882

New issue

Open

opened 2026-02-20 22:14:16 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-20 22:14:16 -05:00

Owner

Originally created by @adf-patrickha on GitHub (Aug 15, 2024).

Description

Mumble raises the "Microphone power" to absurd levels over time (Observable via the Mumble audio statistics). It usually starts at 071%, and goes up to 400+%, which leads to constant loud noise, even when the hardware microphone is muted. This makes the input unusable, until Mumble is stopped. The output device remains
When I close mumble, wait a few seconds and restart it, the settings are back to normal.

This change affects other applications too that use the same input device. Interestingly no change is made on the input device settings. The input level of the device in alsamixer and pulsemixer stay the same. Also the services wireplumber, pipewire, pipewire-pulse do not log anything when Mumble increases the power.

Steps to reproduce

Open Mumble and connect to server
Open Audio Statistics (Self > Audio Statistics)
Wait over time and observe the Microphone power rising.

Mumble version

1.5.634

Mumble component

Client

OS

Linux

Reproducible?

Yes

Additional information

OS: Manjaro
Kernel: 6.6.40-1-MANJARO
Device: ThinkPad T14 Gen 5

Relevant log output

journalctl --user -u wireplumber -u pipewire -u pipewire-pulse -S today                                                                                                                           
-- No entries --

pulsemixer --list-sources
Source:		ID: source-344, Name: PRO Mono, Mute: 0, Channels: 1, Volumes: ['100%'], Default

Screenshots

Audio Statistics while unmuted, without talking:

Audio Statistics while muted:

Originally created by @adf-patrickha on GitHub (Aug 15, 2024). ### Description Mumble raises the "Microphone power" to absurd levels over time (Observable via the Mumble audio statistics). It usually starts at 071%, and goes up to 400+%, which leads to constant loud noise, even when the hardware microphone is muted. This makes the input unusable, until Mumble is stopped. The output device remains When I close mumble, wait a few seconds and restart it, the settings are back to normal. This change affects other applications too that use the same input device. Interestingly no change is made on the input device settings. The input level of the device in `alsamixer` and `pulsemixer` stay the same. Also the services `wireplumber`, `pipewire`, `pipewire-pulse` do not log anything when Mumble increases the power. ### Steps to reproduce 1. Open Mumble and connect to server 2. Open **Audio Statistics** (Self > Audio Statistics) 3. Wait over time and observe the **Microphone power** rising. ### Mumble version 1.5.634 ### Mumble component Client ### OS Linux ### Reproducible? Yes ### Additional information OS: Manjaro Kernel: 6.6.40-1-MANJARO Device: ThinkPad T14 Gen 5 ### Relevant log output ```shell journalctl --user -u wireplumber -u pipewire -u pipewire-pulse -S today -- No entries -- ``` ``` pulsemixer --list-sources Source: ID: source-344, Name: PRO Mono, Mute: 0, Channels: 1, Volumes: ['100%'], Default ``` ### Screenshots Audio Statistics while unmuted, without talking: ![swappy-20240815_112717](https://github.com/user-attachments/assets/68a58380-c762-4ad1-98bb-a1ee37650718) Audio Statistics while muted: ![swappy-20240815_112644](https://github.com/user-attachments/assets/67e8265b-cfe3-4723-88b6-7f69df6d7122)

deekerman added the

audio

bug

help-needed

labels

2026-02-20 22:14:16 -05:00

deekerman commented

2026-02-20 22:14:18 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Aug 15, 2024):

Have you tried disabling automatic gain control?

@Krzmbrzl commented on GitHub (Aug 15, 2024): Have you tried disabling automatic gain control?

deekerman commented

2026-02-20 22:14:18 -05:00

Author

Owner

@adf-patrickha commented on GitHub (Aug 15, 2024):

Have you tried disabling automatic gain control?

@Krzmbrzl do you mean the Max. Amplification settings in Settings > Audio Input > Audio Processing? I have that one on the lowest value 1.00. I don't think there is another setting, matching that description.
Here a screenshot from my input settings:

I also tried disabling the noise suppression, but it did not make a difference.

@adf-patrickha commented on GitHub (Aug 15, 2024): > Have you tried disabling automatic gain control? @Krzmbrzl do you mean the **Max. Amplification** settings in **Settings > Audio Input > Audio Processing**? I have that one on the lowest value **1.00**. I don't think there is another setting, matching that description. Here a screenshot from my input settings: ![swappy-20240815_162213](https://github.com/user-attachments/assets/784ef0f4-0ce3-437b-993c-a0f5045c38c3) I also tried disabling the noise suppression, but it did not make a difference.

deekerman commented

2026-02-20 22:14:18 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Aug 15, 2024):

Hm. I'm not aware of Mumble doing any input level adjustments that would be visible system wide... does this also happen with other audio backends?

@davidebeatrici do you have any idea about this?

@Krzmbrzl commented on GitHub (Aug 15, 2024): Hm. I'm not aware of Mumble doing any input level adjustments that would be visible system wide... does this also happen with other audio backends? @davidebeatrici do you have any idea about this?

deekerman commented

2026-02-20 22:14:18 -05:00

Author

Owner

@davidebeatrici commented on GitHub (Aug 15, 2024):

Unfortunately not. I regularly use PipeWire with similar settings and have never encountered such an issue.

@davidebeatrici commented on GitHub (Aug 15, 2024): Unfortunately not. I regularly use PipeWire with similar settings and have never encountered such an issue.

deekerman commented

2026-02-20 22:14:18 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Aug 17, 2024):

@adf-patrickha does the behavior depend on what input mode (voice activation, PTT, continuous) you are using?

@Krzmbrzl commented on GitHub (Aug 17, 2024): @adf-patrickha does the behavior depend on what input mode (voice activation, PTT, continuous) you are using?

deekerman commented

2026-02-20 22:14:18 -05:00

Author

Owner

@adf-patrickha commented on GitHub (Aug 20, 2024):

@adf-patrickha does the behavior depend on what input mode (voice activation, PTT, continuous) you are using?

No, I haven't used those modes, because they are not really an option for my use-case sadly. PTT does not work well with Wayland, as global hotkeys do not really work. I know RPC sub commands are a thing and I use them for togglemute/toggledeaf. But that does not really work with press/release keybindings from my experience.

And continuous does not work because of background noise and the need to togglemute all the time.
But I can give it a shot temporarily to see if behaves differently 👍

@adf-patrickha commented on GitHub (Aug 20, 2024): > @adf-patrickha does the behavior depend on what input mode (voice activation, PTT, continuous) you are using? No, I haven't used those modes, because they are not really an option for my use-case sadly. PTT does not work well with Wayland, as global hotkeys do not really work. I know RPC sub commands are a thing and I use them for togglemute/toggledeaf. But that does not really work with press/release keybindings from my experience. And continuous does not work because of background noise and the need to togglemute all the time. But I can give it a shot temporarily to see if behaves differently :+1:

deekerman commented

2026-02-20 22:14:18 -05:00

Author

Owner

@adf-patrickha commented on GitHub (Aug 20, 2024):

Same behavior with continuous:

Additional info btw.: I already tried another headset too. So it's not a hardware issue either.

@adf-patrickha commented on GitHub (Aug 20, 2024): Same behavior with continuous: ![swappy-20240820_140426](https://github.com/user-attachments/assets/41567440-b55f-4d7d-bb4a-7cab511fb463) Additional info btw.: I already tried another headset too. So it's not a hardware issue either.

deekerman commented

2026-02-20 22:14:19 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Aug 20, 2024):

Hm okay - I have no idea what's going on. Can you reproduce the same issue on a different machine?

@Krzmbrzl commented on GitHub (Aug 20, 2024): Hm okay - I have no idea what's going on. Can you reproduce the same issue on a different machine?

deekerman commented

2026-02-20 22:14:19 -05:00

Author

Owner

@adf-patrickha commented on GitHub (Aug 29, 2024):

Hm okay - I have no idea what's going on. Can you reproduce the same issue on a different machine?

@Krzmbrzl No, it's not reproducable on another device. None of my colleagues are having this issue either. I only have this issue since switching to a new device (ThinkPad T14 Gen 5). But it's a Mumble specific issue that I'm not having with any other application using microphone input. So Mumble is the trigger causing the issue, but the root cause could also be the sound card or Pipewire for sure.

@adf-patrickha commented on GitHub (Aug 29, 2024): > Hm okay - I have no idea what's going on. Can you reproduce the same issue on a different machine? @Krzmbrzl No, it's not reproducable on another device. None of my colleagues are having this issue either. I only have this issue since switching to a new device (ThinkPad T14 Gen 5). But it's a Mumble specific issue that I'm not having with any other application using microphone input. So Mumble is the trigger causing the issue, but the root cause could also be the sound card or Pipewire for sure.