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*

[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: https://github.com/mumble-voip/mumble/commit/23fa9b3979c244f1bcdbc80972a88ef7144f8f4a

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.0~2458~g176c041~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[bot]]

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.