Add ability for users to adjust another users voice activiation and microphone amplification level

[leonlag]

Context
I often find new mumble users have trouble configuring their microphone properly.

For example:

• You can hear every single noise in their room, even though they have a headset microphone that's designed to be close to the users mouth and therefore needs very little amplification.
• The users microphone is very noisy, so the noise suppression needs to be turned up.
• You can hear their keyboard clacking, which is fixed by adjusting the voice activation levels.

I would then tell these user to adjust their settings, talk, adjust again, rinse repeat. This is especially common with less technical people.

Describe the feature you have in mind
I propose a feature where a user on a server can adjust these settings for them through a little UI, very similar to how you would adjust your own settings. The relevant settings would be in the audio input section of the settings menu, though they should probably be further restricted to voice activity type/levels, microphone amplification and noise filtering.
I don't think settings like the type of transmission(Continuous, Voice activity, PTT) or Compression should be adjustable.

I'm not sure on how the permissions should work yet. Should it just be behind an ACL? Should users receive some kind of pop up window that asks for permission? Should these settings only be retained for the server they were adjusted on?

Additional context
Only the the settings inside blue borders should be adjustable/visible. The microphone level needs to be visible to the person adjusting these settings.

[streaps]

wouldn't this be better solved by better default settings and automatic gain control?

[toby63]

• An Alternative would be to allow activating RNNoise (and maybe also echo cancel?) for incoming audio as well.

• Regarding @leonlag's original idea:
  I am against allowing such a remote access to user settings, but there are three alternatives:

1. Allow a user to set these options only for themselves (just like adjusting loudness per user)

   • would it be possible to set the amplitude for incoming audio?

2. Allow to set these options for the group/channel:

   • maybe the server could process the audio filters then?
   • or the user is forced to use RNNoise for example? (maybe a bad idea)

3. Another different (but similar) and not so intrusive method would be, to suggest settings to the user.
   This way one user could send the suggestions to another user and he/she could apply that (by clicking "yes") or deny it.
   This could maybe work with audio profiles.

In practice it would work like this:

1. User1 has problems, other users notify him about it.
2. User1clicks on a help button.
3. Now User2 can set different audio options and send it as a suggestion/profile to User1.
4. User1 applys that profile.

Problems:
For this to make sense, it would be convenient to have "live-test-apply", so that User2 can hear the result of his proposed changes (before sending the profile).
Only applyable (in a non-intrusive way) if it is possible to simulate this on the computer of User2 (without touching the computer of User1).
The alternative would be trial-and-error (aka sending profiles multiple times, until it works).

---

@streaps

wouldn't this be better solved by better default settings

I think they already are reasonable and especially the audio wizard is testing that well, but its the users who are the problem, because they adjust it or ignore it.

and automatic gain control?

Well at first this idea sounds good, but then again that might not be as easy as it sounds or will not work as good as one might think.

[streaps]

An Alternative would be to allow activating RNNoise (and maybe also echo cancel?) for incoming audio as well.

I don't know how RNNoise works, but echo cancellation cannot be done on the receiving side, it has to run on the local device the speakers and the microphone are connected to.

[streaps]

You want to do the noise reduction before the lossy audio encoder (Opus). The noise masks the speech signal and is also harder to compress.

Noise reduction on the receiving side might have some value (especially with higher bitrates), but it also might introduce unpleasant artefacts (especially with lower bitrates).

[schoerg]

+1 for setting microphone levels and boosting in the Mumble settings. It is counterintuitive (for non-technical people) to have two seperate places where you can adjust your microphone settings. Especially if the Mumble settings don't change microphone levels at all.

[dstensnes]

Could an idea be to implement some kind of "voting" system, where other users can send a "vote" to have another users microphone adjusted up/down, and the voted user could have an "accept"/"reject" set of buttons to do an automatic adjustment followed by an "undo" button. That way other users might at least give suggestion to another mumble client that it's setting might be adjusted in a certain direction? It is a very different solution from every other VOIP system out there, but it could at least help users help each other, while not providing any permanent overhead on the clients

[toby63]

@streaps

I don't know how RNNoise works, but echo cancellation cannot be done on the receiving side, it has to run on the local device the speakers and the microphone are connected to.

Ok, I trust your technical knowledge here, but I imagened that would be possible (at least in theory).
Because: you have your own microfone input & audio send by other users, that you would both hear as an echo from another users input.
So you could use the other audio data to filter that out from the audio received by the problem user (I hope you can follow me).

You want to do the noise reduction before the lossy audio encoder (Opus). [...]
Noise reduction on the receiving side might have some value (especially with higher bitrates), but it also might introduce unpleasant artefacts (especially with lower bitrates).

Interesting, did not know about that.
But that could surely be tested.
I have to admit that I just derived the idea based on readings about Krisp (the new AI-noise cancelling program/library), which can (according to reports) filter on the receiving side in very good quality.
The bad message is, I heard from other users that RNNoise is not so powerful (Some say not nearly as powerful).

@schoerg

+1 for setting microphone levels and boosting in the Mumble settings.

While I agree, some might not.
It is an ongoing debate between purists who think that everything should just be handled by one instance (pulseaudio) and those who want settings in every application.

@dstensnes

Could an idea be to implement some kind of "voting" system

Honestly that is a bit too complicated imo, users can just tell the user to adjust themselves.
The main problem mentioned by the reporter is that some users might be overstrained, so that external help is necessary or useful.

[Krzmbrzl]

It is counterintuitive (for non-technical people) to have two seperate places where you can adjust your microphone settings.

Which places are you talking about? Settings and audio wizard?

would it be possible to set the amplitude for incoming audio?

That's what the local volume adjustment is for

maybe the server could process the audio filters then?

In theory I guess it could but this would add a really big burden to the audio routing process on the server effectively increasing CPU load and increase latency. I don't think that's a good idea...

Another different (but similar) and not so intrusive method would be, to suggest settings to the user.

I guess that could work, but what's the real advantage of such a system vs. just telling the affected user to open the settings and move this and that slider in that and that direction? To follow these kinds of instructions, it doesn't take any understanding at all :shrug

[schoerg]

@Krzmbrzl

Which places are you talking about? Settings and audio wizard?

No. In Windows you have "Control Panel - Audio - Microphone - Levels" then there are two settings (depending on your audio hardware): "Microphone" and "Microphone Boost". Both control the volume of your microphone. Both settings can't be changed in Mumble.

Same with Pulseaudio. there is's called "Input Volume". Users at least need to know that those settings exist and they are critical in setting your microphone correctly.

The "Settings and audio wizard" will not help you there.

@toby63

While I agree, some might not.
It is an ongoing debate between purists who think that everything should just be handled by one instance (pulseaudio) and those who want settings in every application.

It could be handled in pulseaudio too, but then at least a link (or other hint) would be good.

[Krzmbrzl]

Both settings can't be changed in Mumble.

That's simply because these aren't Mumble-specific settings. Though I guess this is where the debate begins. I don't feel like settings done in Mumble should affect other applications (or vice versa for that matter). Thus I'm against performing system settings in Mumble's setting UI.
That however is OT for this issue anyways ^^

[schoerg]

I don't think it's OT. The examples in the opening post can't all be solved within Mumble alone (or would be better solvable in the systems setting).
So any helper system that can only change Mumble settings will have the same disadvantage as the Mumble settings itself. At least showing the current values for input volume/amplification would be great for at least some information about the current state.

Personally, I'm all in for changing the system settings, a perhaps better way would be per-application settings (for both input and output).

[Krzmbrzl]

At least showing the current values for input volume/amplification would be great for at least some information about the current state.

Hm yeah I guess that'd be an improvement to the way things are right now. This still belongs in a separate issue though as it is more concerned with general settings UX than allowing other users to modify your settings for you ☝️

[streaps]

@toby63

Ok, I trust your technical knowledge here,

I might be wrong ;)

but I imagened that would be possible (at least in theory).
Because: you have your own microfone input & audio send by other users, that you would both hear as an echo from another users input.
So you could use the other audio data to filter that out from the audio received by the problem user (I hope you can follow me).

In a 1:1 setting it might work (?), with multiple users I'm not so sure. If there are 10 users, wouldn't it have to do echo cancelling 9 * 9 times in the worst case scenario. I think it's hard to do that reliable and it's always better to apply it on the source.

You want to do the noise reduction before the lossy audio encoder (Opus). [...]
Noise reduction on the receiving side might have some value (especially with higher bitrates), but it also might introduce unpleasant artefacts (especially with lower bitrates).

Interesting, did not know about that.
But that could surely be tested.

Yes :)

I have to admit that I just derived the idea based on readings about Krisp (the new AI-noise cancelling program/library), which can (according to reports) filter on the receiving side in very good quality.
The bad message is, I heard from other users that RNNoise is not so powerful (Some say not nearly as powerful).

I listened to the examples at the Krisp website and they already sounded a bit shitty even with the perfectly recorded lossless source material.

Maybe this is a topic for Github discussions.

[toby63]

@Krzmbrzl

would it be possible to set the amplitude for incoming audio?

That's what the local volume adjustment is for

What I meant was changing the sliders for:
"silence below" and "speech above" (those are not included in the local volume adjustment for other users)

Another different (but similar) and not so intrusive method would be, to suggest settings to the user.

I guess that could work, but what's the real advantage of such a system vs. just telling the affected user to open the settings and move this and that slider in that and that direction? To follow these kinds of instructions, it doesn't take any understanding at all 🤷

In most cases, I would agree with you, but there are some people who might still have difficulties doing that.
A valid case for that might be a blind person (see #4069).
(We might ask a blind person whether thats the case).

[Krzmbrzl]

What I meant was changing the sliders for:
"silence below" and "speech above" (those are not included in the local volume adjustment for other users)

Then the answer is no. If the audio levels are below these threshold values, no audio is sent at all. Thus you can't lower the thresholds on your local machine. I guess you could increase them but I don't think that's a good way of handling it (allowing some people to hear that person while others don't - this could get confusing pretty quickly).

A valid case for that might be a blind person

Potentially, yes. I can't really tell, 'cause I'm not blind. However in that case I think the goal should be to increase the overall accessibility and not to pick out some specific settings that can be set for you by other users...

And btw.: You don't have to always mention me in your answers. I'm receiving notifications for every last thing that happens on this GitHub project anyways ;)

[toby63]

A valid case for that might be a blind person

Potentially, yes. I can't really tell, 'cause I'm not blind. However in that case I think the goal should be to increase the overall accessibility and not to pick out some specific settings that can be set for you by other users...

I agree, but just as a thought:
I don't know how complicated it would be to implement "real" options for blind people, maybe sending (option-)profiles would be an easier intermediate solution.
Maybe @citril could help us?

And btw.: You don't have to always mention me in your answers. I'm receiving notifications for every last thing that happens on this GitHub project anyways ;)

Ok, I thought this is "good" practice here, to make it clear what is belonging to whom.

[Krzmbrzl]

Ok, I thought this is "good" practice here, to make it clear what is belonging to whom.

If we're having a discussion with multiple people involved, it probably is, but if this is a conversation between the two of us and if you're citing the parts you're referring to, I think it is redundant 🤷