The sound of the version 1.4.230 is way worse then 1.3.4 #5448
Comments
|
Did you tinker with the noise suppression and/or echo cancellation options? Both of these systems have received changes between 1.3 and 1.4, so maybe some of that is interfering in your case. |
|
I came here experiencing similar issues. Yesterday, I was using 1.3 with no issues on mic quality. Later in the day, I saw there was the update to 1.4.230 and other users in my server called out either a static sound or a somewhat canny / muffled sound from mic, which hasn't happened in the past. I tried messing with echo cancellation and noise suppression options, but couldn't get the audio to clear up in audio wizard tests. I checked connections with the mic and the Scarlet Solo audio interface and they seemed to be working correctly. I tested my mic in Windows and Discord and didn't run into the same issue. Perhaps it's a special combination of settings between the echo and noise cancellation that I haven't tested yet, but it seems weird that the issue persists even when I tried going back to 1.3 or earlier versions of Mumble. Is there any way the update to Mumble changed drivers or some other setting I'm unaware of? |
|
No Mumble doesn't change any drivers. You could clear the registry though in order to make sure you get rid of all Mumble settings |
That sounds pretty much like the issues we encountered.
Yes, we did tinker with those settings. We turned everything off, too. But sadly nothing changed. If I think about it... I had looong time ago such a situation with Teamspeak. |
|
Sounds like maybe the CELT codec is used. Try forcing Opus by setting opusthreshold in the server config to 0. |
|
Yes that would definitely be worth a try. And yes we should definitely get rid of that old CELT stuff |
|
It seems like for some reason the noise suppression changed from Speex to RNNoise in the new version. Under |
|
Okay, I did as advised (forced Opus) and now, when we turn off the RNNoise it is way better! |
|
Are the input levels on your mic perhaps rather high? RNNoise is known to cause really bad audio when the input audio is clipping |
It's because that's the new default, iirc. Okay but by enforcing Opus and disabling RNNoise the issue is fixed? |
I'm not the issue opener but we've had 5 people upgrade so far and every single one has static noises on their mic after the upgrade and switching back to Speex has immediately restored the quality to the level before the update. We were all using Opus, RNNoise is what was at fault. |
|
RNNoise is really weird - some swear that it is the best noise suppression ever, working magically well and others, like you, report that it is complete garbage. Maybe it only works for certain types of input devices or setups 🤔 |
Yes. Opus forced by the server and RNNoise off is helping greatly. After some testing, we figured, that these settings mights sound even better than what we had with 1.3.4: |
|
random thought: maybe this rnnoise depends on the sample rate? |
|
The sample rate is hardcoded at 48 kHz |
|
I've noticed this as well using several of the older 1.4.0 development builds. The users that had RNNoise enabled had discernably worse transmit quality (can't remember the exact details as it was months ago) on a server with a maximum audio bandwidth of ~100Mbps (yes, Mbps) - each user typically has their audio input settings as high as they will go quality-wise. At least one of those users was using an identical input setup to me: MXL AC-404 USB mic, Windows mic volume set to ~80, Windows format set to the default of 1 channel/16 bit/48KHz. Coincidentally, those that had RNNoise enabled also suffered from the issue described in #4538. |
|
Has anyone been able to reproduce this on another OS than Windows? |
|
This support-issue has been automatically marked as stale because it has not had recent activity. If no further activity occurs, the issue will be automatically closed as we'll assume your problem to be fixed. |
stale
bot
added
the
stale-support
|
Hold on, stale-bot. I still want to change the defaults based on this issue.... |
stale
bot
removed
the
stale-support
Yes. We had a single user with this problem on Linux. After the upgrade from 1.3.4 to 1.4 their sound quality was pretty bad. Tweaking the RNNoise parameters did not help. Only after switching manually to Speex the sound quality was the same as before. Note that their microphone was a fairly low-tier one with some static noise present in raw recordings. |
|
One thing I've noticed is that ever since I updated to 1.4 my friends, who are still on 1.3.4, say my audio quality is sometimes terrible and laggy while the ones who also updated to 1.4 say it's always completely fine. Could this be the same issue? Is the client version mismatch somehow to blame? |
|
No that seems unrelated. The different versions shouldn't affect audio quality at all (afaict) 🤔 |
Hmm... our microphones are fine. We don't have any interferences while recording. |
|
I'm also having the same problem on Gentoo Linux and Pipewire. I can also report that I had this problem on earlier 1.4.0 development builds. Strangely, if I apply RNNoise directly in Pipewire instead of using the Mumble settings UI to do it, I get the same behavior. This did not happen on 1.3.4. |
|
One of my friends has similar issue with 1.4.230 version. The sound in 1.3.4 was deeper, with better dynamics. 1.4.230 has shallow sound and the voice sounds kinda metallic, with distortions. We tried reducing noise filter strength but it didn't work unless we disabled all noise filters. The microphone is almost studio quality with very little to none noise and great dynamics (novox nc-1). |
In the 1.4.230 release, we enabled RNNoise by default as there have been lots of reports of how well it works. However, after the release we saw numerous reports complaining about bad audio quality, which was traced back to having RNNoise enabled. For some reason the outcome of having RNNoise enabled is very different in different scenarios. Sometimes it works miraculously well and other times it worsens the audio quality to an unbearable level. There seems to be a higher chance of RNNoise messing up, when using Windows, but the same effect has also been observed on Linux. It might also depend on the quality of the used microphone (better quality = less noise -> RNNoise starts doing weird stuff), but we don't have any definitive clues yet. Because of this, we will change the default noise cancelling mode back to Speex so that everyone for whom RNNoise actually works, cna enable it, but we don't kill the experience for many folks by using an unsuitable default value. Fixes mumble-voip#5448
In the 1.4.230 release, we enabled RNNoise by default as there have been lots of reports of how well it works. However, after the release we saw numerous reports complaining about bad audio quality, which was traced back to having RNNoise enabled. For some reason the outcome of having RNNoise enabled is very different in different scenarios. Sometimes it works miraculously well and other times it worsens the audio quality to an unbearable level. There seems to be a higher chance of RNNoise messing up, when using Windows, but the same effect has also been observed on Linux. It might also depend on the quality of the used microphone (better quality = less noise => RNNoise starts doing weird stuff), but we don't have any definitive clues yet. Because of this, we will change the default noise cancelling mode back to Speex so that everyone for whom RNNoise actually works, cna enable it, but we don't kill the experience for many folks by using an unsuitable default value. Fixes mumble-voip#5448
n the 1.4.230 release, we enabled RNNoise by default as there have been lots of reports of how well it works. However, after the release we saw numerous reports complaining about bad audio quality, which was traced back to having RNNoise enabled. For some reason the outcome of having RNNoise enabled is very different in different scenarios. Sometimes it works miraculously well and other times it worsens the audio quality to an unbearable level. There seems to be a higher chance of RNNoise messing up, when using Windows, but the same effect has also been observed on Linux. It might also depend on the quality of the used microphone (better quality = less noise -> RNNoise starts doing weird stuff), but we don't have any definitive clues yet. Because of this, we will change the default noise cancelling mode back to Speex so that everyone for whom RNNoise actually works, cna enable it, but we don't kill the experience for many folks by using an unsuitable default value. Fixes #5448
In the 1.4.230 release, we enabled RNNoise by default as there have been lots of reports of how well it works. However, after the release we saw numerous reports complaining about bad audio quality, which was traced back to having RNNoise enabled. For some reason the outcome of having RNNoise enabled is very different in different scenarios. Sometimes it works miraculously well and other times it worsens the audio quality to an unbearable level. There seems to be a higher chance of RNNoise messing up, when using Windows, but the same effect has also been observed on Linux. It might also depend on the quality of the used microphone (better quality = less noise => RNNoise starts doing weird stuff), but we don't have any definitive clues yet. Because of this, we will change the default noise cancelling mode back to Speex so that everyone for whom RNNoise actually works, cna enable it, but we don't kill the experience for many folks by using an unsuitable default value. Fixes mumble-voip#5448 (cherry picked from commit 73adfce) # Conflicts: # src/mumble/Settings.cpp
In the 1.4.230 release, we enabled RNNoise by default as there have been lots of reports of how well it works. However, after the release we saw numerous reports complaining about bad audio quality, which was traced back to having RNNoise enabled. For some reason the outcome of having RNNoise enabled is very different in different scenarios. Sometimes it works miraculously well and other times it worsens the audio quality to an unbearable level. There seems to be a higher chance of RNNoise messing up, when using Windows, but the same effect has also been observed on Linux. It might also depend on the quality of the used microphone (better quality = less noise => RNNoise starts doing weird stuff), but we don't have any definitive clues yet. Because of this, we will change the default noise cancelling mode back to Speex so that everyone for whom RNNoise actually works, cna enable it, but we don't kill the experience for many folks by using an unsuitable default value. Fixes mumble-voip#5448 (cherry picked from commit 73adfce)
In the 1.4.230 release, we enabled RNNoise by default as there have been lots of reports of how well it works. However, after the release we saw numerous reports complaining about bad audio quality, which was traced back to having RNNoise enabled. For some reason the outcome of having RNNoise enabled is very different in different scenarios. Sometimes it works miraculously well and other times it worsens the audio quality to an unbearable level. There seems to be a higher chance of RNNoise messing up, when using Windows, but the same effect has also been observed on Linux. It might also depend on the quality of the used microphone (better quality = less noise => RNNoise starts doing weird stuff), but we don't have any definitive clues yet. Because of this, we will change the default noise cancelling mode back to Speex so that everyone for whom RNNoise actually works, cna enable it, but we don't kill the experience for many folks by using an unsuitable default value. Fixes mumble-voip#5448 (cherry picked from commit 73adfce)
The issue
The sound transferred using a 1.4.230 Mumble client is way worse compared with the previous 1.3.4 version.
To make that clear, the systems and microphones used are identical. (> All what changed is the Mumble client)
And the results are reproducable with multiple PCs and setups.
It's tough to describe but it sounds very "muffled" and robotic in direct comparison.
Also noticable is a very high latency (without any changes to server or network?).
We didn't manage to improve the results through changing the "input" or "output" settings.
So, we will change back.
Is there anything to improve on our end?
Otherwise we can't really upgrade. Which is very sad, we would like to stick with mumble in the long run :(
Mumble version
1.4.230
Mumble component
Client
OS
Windows
Additional information
Official Murmur Server on Ubuntu Server -> Version 1.3.4, since there is no update yet.
The text was updated successfully, but these errors were encountered: