Strange Opus audio bug affecting at least 2 of our users.

[mumble-voip]

This has been an ongoing problem with at least 2 of our users ever sense Opus was implemented. Our workaround is to force the server to use Celt though the overall sound is not near as good.

The server is Arch Linux 64 running the latest git snapshots and this problem still exists as of Feb 10 2013.

The clients are all Windows running current snapshots.

User 1: The most frequently affected has used multiple different MICs, headsets and has recently had to switch MOBO and CPU due to a recent MOBO failure. Sadly this didn't fix the problem. The problem also persists between windows 7 and 8. Next time he is in Linux I will test if he still has the problem. I'm attaching his dxdiag and an audio sample.

User 2: Affected far less often. Has nearly the same hardware as I. The only notable difference is he is running 3 AMD GPUs vs my one Nvidia GPU. He has recently switched from an M-Audio Producer USB Mic to a Logitech G930 and still the problem persists.

User 3: Me, not affected at all, other than the ear shattering pain... Only other notable differences from User 2 I can think of is I'm using a Killer 2100 Nic “Don't judge me I got it for free.” and i'm using a Blue Yeti MIC. I haven't had this problem in windows 7 8, Arch Linux 64 and FreeBSD 9.1.

This ticket has been migrated from sourceforge. It is thus missing some details like original creator etc.
The original is at https://sourceforge.net/p/mumble/bugs/957/ .

*The following attachments were added on the original item:

• https://sourceforge.net/p/mumble/bugs/957/attachment/User3.DxDiag.txt*

[mumble-voip]

Hmm can't add multiple files. Attached User1 dxdiag and audio sample.

Some system info from the murmur server.
OS: Arch Linux x86_64
Hostname: salmac
Uptime: 49 days, 6:35
Kernel: 3.6.10-1-ARCH
Shell: /bin/bash
Packages: 326
Window Manager: unknown
RAM: 2466 MB / 7973 MB (30%)
CPU: AMD FX(tm)-4100 Quad-Core Processor
Boot: 31M / 464M (7%) (ext4)
Root: 72G / 440G (18%) (ext4)

The following attachments were added on the original comment:

• https://sourceforge.net/p/mumble/bugs/_discuss/thread/c56f11bc/ada4/attachment/User1.DxDiag%26Flac.7z

[mumble-voip]

IRC log for clarification.

[10:26] <Ben_Mumble_com> RED-404: what is the problem? "Ear shattering pain" for the listeners?
[10:27] <RED-404> yes check the sample file in User1.DxDiag&Flac.7z
[10:28] <RED-404> its only with opus and every listener in the chan will hear it
[10:29] <Ben_Mumble_com> I see
[10:31] <DireFog> Sheesh that sounds like Metallica
[10:32] <Ben_Mumble_com> "using opus, certain users appear to send sound that is "ear shattering pain" at random times: Is that description of the problem?
[10:33] <RED-404> we'll all users I think the problem is on the broadcasters' side
[10:34] <DireFog> does everything they say sound like that, or it it just for a while when they start talking?
[10:35] <RED-404> one thing we were going to check is if it had something to do with cool & quiet. The CPU jumping frequencies from ~800 MHz to 2.4GHz
[10:36] <DireFog> that shouldn't be a problem unless people are on really broken WinXP systems
[10:36] <RED-404> and its not constant but its frequent
[10:38] <Ben_Mumble_com> in the "ear shattering pain" do you hear voice at all?
[10:39] <DireFog> so they get normal after a while without restarting the client?
[10:40] <RED-404> I have a 6 min audio clip of him and he only does it one time and yes I hear voice sometime it lasts for 4 to 6 words and its still understandable
[10:40] <RED-404> god I can't spell need sleep
[10:41] <RED-404> and no it never normalizes or fixes itself it can be as frequent as every third word or as infrequent as not happening for 2hr
[10:41] <DireFog> could you check if they have the maximum gain for AGC set really high? It could be an effect of extreme clipping hitting the CODEC
[10:42] <DireFog> hum then it's rather something different
[10:42] <Ben_Mumble_com> RED-404: I would submit this conversation with your bug report for further clarity
[10:42] <RED-404> normally the gain is set between default and 1

[mumble-voip]

Wish you would have included the issue description in your initial report. I spent forever trying to find if a bug report was opened for this.

We recently started using opus on our server and ever since then messages that my friend transmits have a small chance to cause ear shattering pain. Maybe once every 100 times he talks it does this, but when it happens it's like a bomb went off and my ears ring. It is seriously THAT LOUD which in my opinion makes this a very serious bug (potential for hearing damage). It's to the point where I cannot use Mumble with him anymore unless I don't use the headset, because it causes physical pain to my ears. If there is another user in the channel they hear it too. You can barely understand what they were trying to say in their transmitted message because it seems like the gain is set to +10000dB. Then the next thing they say will be at normal, human-safe volume.

We are all using the latest snapshot. He is using windows 8 with his laptop's integrated Conexant audio with the latest drivers available.

This never happened when it was using the old celt codec. Not even once.

[mumble-voip]

I can also confirm that we've had this issue on our Mumble server as well. Are there any updates on this issue?

[hacst]

Unfortunately not at this point. We haven't been able to willfully reproduce this issue up to now so if anyone can come up with reliable steps to do so that would be incredibly helpful.

[ghost]

I'd like to confirm I am also seeing this issue with both my audio output on Linux and two other users I know on Windows. Some users do it some don't no idea how to reproduce.

[ghost]

I had a friend switch from push to talk to voice activation and now he seems to have the problem too maybe this will help with reproducing the error. Settings are:

Mumble version: 1.2.4
Echo: Mixed
Voice Activity: Amplitude
Voice Hold: 0.50s

I highly think it's to do with using voice activation.

[petercrabtree]

Can't produce this issue at will, but at least two of the users on my server have this issue as well--the first second or so of activity sounds like it's being put through an amp set as high as it goes (distortion, incredibly loud). What can I get you guys to help diagnose this issue?

[frymaster]

Our server seems to be experiencing this issue as well. It can happen in the middle of someone speaking. It happens to people on push to talk or voice activation. We cannot reproduce it at will and have no idea what factors might cause it. When it happens, everyone hearing the person will hear the sound. Afterward, if the person had 0 lost/late packets before, they still will afterwards. Our only option has been to set Opus threshold to 100% and keep a non-opus-supporting client connecting, forcing CELT.

[Natenom]

A recorded audio file with this issue can be found here: http://files.natenom.com/public/mumble/bugs/baeh/01.wav
Maybe helpful.

[druska]

I have the same problem affecting everyone in my server. It occurs mostly when people first start talking. It's being hosted on an Amazon EC2 instance running Ubuntu 12.04. The server is using the default config, but the noise it occurs with both opusthreshold=100 and opusthreshold=0. Mumble Server Information lists the CELT 0.11.0/Opus codec with 72 kbit/s max.

[druska]

I recorded 2 instances of this for some more examples (mixed into 1 flac). This is on the Opus codec.
https://druska.s3.amazonaws.com/2+mumble+loud+screeches.flac

[Kissaki]

When talking with Natenom today he said I had the issue (Opus audio artifact at beginning of talking) quite often.
After I disabled noise suppression it was gone.
After a bit I enabled noise suppression again (-30dB) and the issue occured again, but with lower intensity (I was told).

[druska]

Thanks for the report, Kissaki. I'll test that as well.

[jairuncaloth]

I'm running a mumble server on Ubuntu 14.04. We experience this issue randomly. It seems to follow certain users more then others.

[jsalts]

Also experiencing this issue. Only change I made on the server is limiting the bandwidth to 60kb/s. Once in a while someone talks and there is ear shattering pain from the volume.

[Atrixium]

I too have been having this issues, has anyone found a work around? I've tried having my players reduce their quality settings down, but it doesn't seem to help even at 10kb/s.

[petercrabtree]

The best workaround is to disable Opus. It sucks, but at least your ears will stop bleeding.

[Atrixium]

How do you disable Opus, I can't seem to find any reference for it?

[jzelinskie]

@Atrixium http://wiki.mumble.info/wiki/Murmur.ini#opusthreshold
If you set this value over 100, it can never be reached, thus the server will always use CELT.

I've been using this workaround since Opus was first added into beta (which is years now).

[n0rc]

@jzelinskie
Thanks, this works for me. Hopefully that bug in Opus will get fixed soon.

[shulima]

Really glad to see there at least is a workaround. After the last bug-induced screech on mumble, my ear is actually hurting.

[wrycu]

Has a root cause been identified? Are there any planned fixes? I'm glad to see there's a workaround, but not so glad to see we have to lose voice quality for it.

[mgalvey]

Is there anything we can do to narrow down the cause of this? I'd be willing to run a debug build of Mumble (and have the users on my server "causing" the problem do the same) to try and determine what causes this.

[KappaNitori]

This issue has been plaguing my server for a while now, and it seems to be getting worse. It follows me the most- other users occasionally transmit a pop or quick beep at the front of a transmission, but apparently my client is sending out long screeches that sound just like the attached audio samples that have been posted earlier in this thread. Found this thread, tried disabling noise suppression, no luck. We're all running push to talk, and since I rent the server through mumble.com, their UI won't let me set the opus threshold over 100. (Can anyone think of another workaround in the meantime?)

If this helps at all, long ago before this screeching problem started but after the 1.2.4 release, some of our users found out how to intermittently induce a strange audio artifact. By disconnecting and reconnecting to the server while holding the push to talk key and speaking right as the connection is made, sometimes the transmission would get a strange burst of reverberation, making the transmitted voice sound like the fictional "Geth" character Legion from the Mass Effect series, or like shouting into a PVC tube- some of our users found it quite amusing but it was never a 100% certain occurrence. Potentially unrelated, but I figured it bears mentioning.

[avatias0]

can confirm it is screech-tastic. tested with mumble-server hosted on both debian and windows
Started off only affecting certain users but now everyone is having a screech. Trying the workaround, hope it works

[LaikeSF]

Our server is having similar issues, we actually stopped running Mumble for a while because of it. We decided to give the 1.3.0 snapshot a try today and we encountered the screeching bug a few hours into use. Not sure how we can help, but we'd love to go back to OPUS as soon as it's fixed. In the mean time, we've switched back to CELT.

[abextm]

I have more data, now in the form of opus data. You can find the opus here. The bad noises supposedly happen at about 43 seconds in, but as you can tell this is not recorded. The recorder does not modify the opus data in any way, however it does discard metadata, such as sequence number and position.

[abextm]

I wrote a quick client with gumble to replay the opus data. It didn't trigger the bug. This narrows the problem down to something with metadata or timing (probably). I doubt its a timing bug because it always (at least for my users) triggers for everybody at once, and I doubt a timing issue could be propagated so reliably over our varying connections.

[mkrautz]

@abextm My comment about it being sender-side was because we fixed a bug a while ago (and backported it to 1.2.x), which could cause a similar screech: 23fa9b3

So if some people on the server were on a version that does not contain the fix, those people could produce a noise that would be heard by everyone else on the server. (That is, one person with an old client could ruin it for everyone else, because the noise is produced in AudioInput.)

[mkrautz]

@abextm Thanks for working on this, BTW!

[mkrautz]

BTW, was the speaker in the recording using VAD, Continuous, or PTT?

[abextm]

Excluding the bot, everyone was on Mumble 1.3.0~2389~gdde8173, using Voice activity.

[DGMurdockIII]

Nice if this gets fixed Voice activity might be actually OK to use then if set up right

[ghost]

About a month ago I enabled Opus again. We had screeches, but one of my visitors was using an old version of Mumble, I can't recount but I think it was around 1.2.10. I told him to upgrade to 1.2.19 and since then we haven't encountered the screeching bug.

Everyone is using Voice Activity and the (Murmur) server version is 1.2.19 on Alpine Linux. It's fixed for us, so thank you!

[davidebeatrici]

We have updated Opus to version 1.2.1.

Could you check if the issue still appears with the latest snapshot (1.3.02458g176c041~snapshot)?

[davidebeatrici]

I have deleted these two comments because they are failed delivery mails sent from Junk Email Filter, because avatias0's email address isn't available anymore and he is subscribed to this issue.

Every time somebody posts a comment (such as this one), a new one from avatias0 appears. Sadly there is nothing we can do.

Let's hope this issue is solved, otherwise I propose to move the discussion to a new issue.

Update: No new comments after mine, maybe the user disabled the service.

[davidebeatrici]

I'm assuming this is not an issue anymore.

[abextm]

Nope still happens, and I still can't repro it in any way

[davidebeatrici]

@abextm Does it still happen?

[abextm]

Very rarely, but it does still happen

[davidebeatrici]

Is there at least a user running an old version of Mumble?

[abextm]

Server is on a slightly modified f2cbebd

There are clients connected that use old versions of gumble, however these clients never have sent audio that causes the bug, and if they receive audio where other clients would hear the bug they are able to decode it without the bug. source
When the bug does occur all of the normal mumble clients hear it simultaneously

Here are some versions that have been connected to the server recently. The bug only happens about once a month anymore, so I can't provide any more specifics on which clients are connected.

• 1.3.0~2729~g2126495~snapshot
• 1.3.0~2586~g894ade2~snapshot

[Krzmbrzl]

Is this still a thing?

[github-actions]

This issue has been marked as stale, because our request for more information has thus far not been fulfilled.

If no further action occurs, this issue will be closed within 7 days.