Replies: 17 comments
-
wouldn't this be better solved by better default settings and automatic gain control? |
Beta Was this translation helpful? Give feedback.
-
In practice it would work like this:
Problems:
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.
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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). |
Beta Was this translation helpful? Give feedback.
-
+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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
Ok, I trust your technical knowledge here, but I imagened that would be possible (at least in theory).
Interesting, did not know about that.
While I agree, some might not.
Honestly that is a bit too complicated imo, users can just tell the user to adjust themselves. |
Beta Was this translation helpful? Give feedback.
-
Which places are you talking about? Settings and audio wizard?
That's what the local volume adjustment is for
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...
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 |
Beta Was this translation helpful? Give feedback.
-
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.
It could be handled in pulseaudio too, but then at least a link (or other hint) would be good. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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). Personally, I'm all in for changing the system settings, a perhaps better way would be per-application settings (for both input and output). |
Beta Was this translation helpful? Give feedback.
-
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 ☝️ |
Beta Was this translation helpful? Give feedback.
-
I might be wrong ;)
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.
Yes :)
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. |
Beta Was this translation helpful? Give feedback.
-
What I meant was changing the sliders for:
In most cases, I would agree with you, but there are some people who might still have difficulties doing that. |
Beta Was this translation helpful? Give feedback.
-
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).
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 ;) |
Beta Was this translation helpful? Give feedback.
-
I agree, but just as a thought:
Ok, I thought this is "good" practice here, to make it clear what is belonging to whom. |
Beta Was this translation helpful? Give feedback.
-
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 🤷 |
Beta Was this translation helpful? Give feedback.
-
Context
I often find new mumble users have trouble configuring their microphone properly.
For example:
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.
Beta Was this translation helpful? Give feedback.
All reactions