[1.4.230] [Windows 10] Sound sporadically stops entirely

[theAkito]

Description

Since about 2 years the sound in the client (In & Out) stops from time to time. Sometimes it happens pretty often in a day, sometimes it does not happen at all, but I'd say that on average it happens at least once every second day.

I am very certain, that it is related to some driver issue. I can reproduce similar (not same!) behaviour generally on Windows, if I increase the sample rate and bit depth to really high levels. In that case, sound is generally choppy and never works as it should. However, when reducing the sample rate and bit depth of the particular device in the sound settings, then everything works as intended.

The only program on my entire computer which uses sound (I have lots of different programs that use sound, starting with TeamSpeak plus other voice chats up to actual DAWs for music production) and has this issue of the entire sound freezing sporadically is only Mumble. That's also why I'm certain it must be particularly a bug in Mumble, as literally all other software which uses sound never shows this symptom, ever.

The sound freeze works like this:

1. You listen to someone talk on Mumble.
2. Suddenly, you don't hear the person anymore.
3. You go to the settings and see on the Audio Input page how the transmission bar (red, yellow, green) has the indicator frozen in the position of how loud your microphone was, when it froze.
4. To work around the issue, all you have to do is click Apply in the same settings window and it starts working again.

This issue can become extremely annoying if it either happens more often than usual, or when you are explaining something and you don't notice how your sound froze, so the other person cannot hear you, but you keep talking for a minute.

I want to explicitly emphasize again, that this issue ONLY ever happens in Mumble, not in any other program that uses sound, like e.g. TeamSpeak or anything else. This is to demolish the opportunity to blame my device, my drivers or my PC set up, even though it works in every way, except in Mumble's client.

I suspect, the symptoms might get triggered more often, when a game is launched or another program is taking charge of the sound device. I assume, this should be related. However, this case happens rarely, so I cannot be sure about it.

I am using a Steelseries Arctis Pro Wireless headset, which has two audio outputs, one for "Gaming" (basically the default sound for everything except Chat) and one for "Chat" (only for Chat, like e.g. Mumble & TeamSpeak). Obviously, I use "Chat" for Mumble's audio output, as intended. It's probably related to the device, as I seem to be so far the only one with that problem in the circle of people joining my server, as they have different headsets. However, it's just a more advanced device, that should work just as well as a $50 Headset.

Due to mentioning this specific device, I have to emphasize again, that this issue ONLY ever happens in Mumble, not in any other program that uses sound, like e.g. TeamSpeak or anything else. This is to demolish the opportunity to blame my device, my drivers or my PC set up, even though it works in every way, except in Mumble's client, i.e. this needs to be fixed in Mumble and is not an issue with other things.

Steps to reproduce

1. Open Mumble.
2. Join your server.
3. Let someone else join the same room as you.
4. Explain something for a while.
5. Notice how you have talked for 3 minutes, without the others hearing you.
6. Open Settings.
7. Click Apply.
8. Sound works again.
9. Repeat until next incident.

Mumble version

1.4.230

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

It's "reproducible", as in, if you talk long enough, then it will happen eventually. However, it's hard to reproduce it voluntarily, exactly at the time you want to reproduce it.

This problem is independent of actual sound usage. If you stay on the server for hours, without talking or using the input & output, at all, the sound can still freeze and you have to unfreeze it, before starting to talk after hours of not doing anything.

It's not a server issue. It's entirely client-side. For example, when the symptoms are showing, only the client with the audio freeze has an issue. All other people on the server can still talk and not notice, how one person in the room is affected by this issue.

This issue happens since a pretty long time, but I hoped it would be fixed at latest with the next minor version, i.e. 1.4. However, I still see no fix, so I am reporting this issue, after all.

This issue survived multiple Windows re-installations.

Relevant log output

There is no log output regarding this issue. It's a client side random driver issue.

Screenshots

This is how the settings page for audio input may look. The active input sound bar is frozen at any position and won't move. Clicking Apply works around the issue, until it happens again.

[Krzmbrzl]

Does this issue also occur when using e.g. push to talk or continuous transmission mode?

[theAkito]

@Krzmbrzl

Never tried it, because I always use Voice Activity in every voice chat program.

[Krzmbrzl]

could you try it out then, please?

[theAkito]

@Krzmbrzl

Well, I can certainly try trying it out. Though, it would take days to be sure that it works better, as the issue sometimes does not happen for a day.

If this trial would bring us closer to actually fixing the issue, I would try using the other modes.

I will come back to this issue, when I have results. Could be later today (if the issue still appears) or at longest, in three days (if the issue is gone).

[Krzmbrzl]

Yeah I think it would be helpful. If the issue can not be reproduced in either of the other modes, the issue most likely lies somewhere in the VAD-specific code whereas it is probably in the general audio processing if you can still reproduce it.

[theAkito]

@Krzmbrzl

So far, when using continuous transmission mode, the issue did not re-appear once. Seems like this is the right track.

[bryanmr]

Edit: This was probably not related to the headset for me. After more debugging, turning on force TCP in the network settings worked around this.

I see this issue on my Steelseries Arctis 1 Wireless with Windows 11. I didn't see it before. I downgraded Mumble back to 1.3.4 and the issue is still present.

https://steelseries.com/gaming-headsets/arctis-1-wireless

For me, the rest of my sound continues working and I continue transmitting. I do not hear anyone on Mumble. So, it is a receive only issue and only seems to impact Mumble.

[theAkito]

I continue transmitting. I do not hear anyone on Mumble. So, it is a receive only issue and only seems to impact Mumble.

Interesting. In my case it definitely stops transmitting. Are you absolutely sure it continues to transmit for the entire time?

[bryanmr]

I continue transmitting. I do not hear anyone on Mumble. So, it is a receive only issue and only seems to impact Mumble.

Interesting. In my case it definitely stops transmitting. Are you absolutely sure it continues to transmit for the entire time?

Edit: This was probably not related to the headset for me. After more debugging, turning on force TCP in the network settings worked around this.

Yeah. They definitely hear me. People tend to send me messages to let me know that I can't hear them, since I tend to keep a one sided conversation going. :)

I've had the headset for a year or more, and this is a new thing. Unfortunately, I changed to the new Mumble 1.4.230 and Windows 11 at the same time, so I don't know if there are other factors even though I switched back.

The continuous transmit setting seems to workaround the problem for me as well. I have a feeling it is the same root cause with a slightly different symptom. It's weird that me transmitting constantly makes it so I can hear people.

[live4ever]

I have this issue with Continuous Transmission on Win10 as well (have had it in 1.3 release series as well). Seems it is the same as issue #4992 with audio engine.

[theAkito]

Seems it is the same as issue #4992 with audio engine.

Not sure, if it's the same. Seems different in some important(?) aspects. Definitely very similar, though. Maybe both issues have more or less the same root cause.

[bryanmr]

This ended up not being related to the headset for me. After more debugging, turning on force TCP in the network settings worked around this. Likely having the continuous transmit masked my crappy Internet in some way.

[Krzmbrzl]

@theAkito do you have a different audio backend than WASAPI available to select from within Mumble? If so, it might be interesting to see if changing the audio backend has any influence on the issue you are seeing.

[SlimGary]

I have the same issue but using Push to talk. Well, i'm not sure that's the same issue, I have to wait to get the same error to try the " apply " fix ; I usually close mumble and re-open it to fix it

For me, it usually happens after a while without talking . Lilke, I stay on the server when I leave the computer, and when I come back , a lot of people are on the same channel than me, nobody can hear me , I can't hear anybody. I just quit and come back and it works like a charm. The same issue happens to a friend of mine aswell.

[Krzmbrzl]

@SlimGary does your little avatar inside Mumble light up blue when you are attempting to transmit audio? Or does it stay green?

[SlimGary]

it turns blue, like the push to talk seems to work. I can type in the chat, people can see it, and I can see the chat aswell. I don't know it if can help ^^'

[Krzmbrzl]

Alright in that case the issue is likely to be found it the UDP connection to the server. Could you try forcing TCP in Mumble's settings? If the issue is with UDP, then this should in principle fix it :thinking:

[SlimGary]

Ok ill give it a try and see what happens. I'll set a reminder and come back to you in a few days.

Thanks !

[ghost]

I run a small mumble server and 2 out of around 10 people have this exact issue. They talk for a bit, then we stop hearing them and they need to open settings and hit "apply" to be heard again. The affected client can still hear all channel participants during the failure and the icon next to their name turns blue on their end but not for anyone else in the channel when they speak. Changing the audio backend and setting TCP-only mode had no effect. Both clients are on windows and one reports using version 1.4.287, that same person reports that the issue happens on application launch, as well as when starting up any video game.

[theAkito]

the icon next to their name turns blue on their end but not for anyone else in the channel when they speak.

Does it turn blue forever or only when they speak? When it was stuck for me, it turned blue once & stayed blue.

they need to open settings and hit "apply" to be heard again.

Did they check, whether the loudness level bar was stuck in its place, randomly? Was also always stuck for me.

Both clients are on windows and one reports using version 1.4.287

If it's fine for them & you, it would help if you would ask about the previously mentioned issues & what Windows version they have exactly & perhaps whether they have something special or weird on their computer. We probably all have something in common...

[SlimGary]

Alright in that case the issue is likely to be found it the UDP connection to the server. Could you try forcing TCP in Mumble's settings? If the issue is with UDP, then this should in principle fix it 🤔

It looks like it works with TCP forced ... Do you know why UDP is messed ?

[ppfeufer]

TCP vs. UDP explained:

[Krzmbrzl]

If I knew exactly why UDP sometimes messes up without Mumble noticing (if it did it would switch to TCP automatically) I would have already fixed it. Unfortunately, I have no idea why Mumble doesn't detect such situations (nor what exactly is the root cause for it, other than UDP being a much less reliable protocol than TCP)

[theAkito]

@Krzmbrzl

Not sure, if that would be too great anyway, as it would fix the symptom, but not the root cause. Since, it is possible to make it "work again" by re-applying the settings, there is something going wrong, deep in the structure.

However, your attempt is suitable as a workaround.

Is it possible for the client to detect, whether the sound volume level detection is stuck? For example, if the input volume is above 0, but is stuck at a certain random level, this would indicate an error, as real sound is never at precisely the same level for more than one or two ticks.

If this can be detected, it would already be a safe bet for a workaround.

Though, this way, I doubt we would ever find the root cause of all this.

[Krzmbrzl]

My workaround was more tuned towards the more common issue where UDP packets seem to not arrive at their destination. From the reports I saw so far, the audio processing freezing as you encounter it, seems rather rare :thinking:

[FREEZEball]

Can confirm the same bug with the same workaround happens on ArchLinux, with the latest Mumble version in repos (1.4.287-5).

[fragtion]

I couldn't hear other users in my Mumble client (v1.4.230) - If I join the server, I hear sound for just a brief moment (about half a second), and then it cuts out

Tried updating to 1.5.517, but the problem continued...

I figured out what solved it, was unmuting myself, and sending a brief transmission. Then I can hear everyone else again and can mute my own mic.

So basically, if I join the server with myself muted and don't transmit anything, then I also can't hear anyone else until I've made some transmission from my side...

Windows 11 Insider Dev 25309.1000 (FWIW...)

[squeaktoy]

Reproducable by my friend. Version: 1.5.634 (1.5.634) OS reported by Mumble: Windows (Windows 10 Home 2009 22631.4460 [x64]) Actual OS: Windows 11 23H2 ISP: Ziggo Modem: Ziggo, black modem IP version: IPv6