Mumble: [Potential Bug] No audio from other users

[toby63]

Short Description:
With a client based on master-branch build (from April, see below) I could not hear other users, who used clients with version 1.3.0.

Details:

The Versions in use:
| User/Server: | OS: | Mumble version: |
| ----------------- | ----- | ---------------------- |
| Server | Debian Testing (most recent) | My Version see below |
| User 1 (me) | Debian Testing (most recent) | My Version see below |
| User2 | Windows 10 (64-bit) | 1.3.0 |
| User3 | MacOS | 1.3.0 |

My Version (master-build):
Some time ago I compiled the master-branch from this commit (from 22nd April):
https://github.com/mumble-voip/mumble/commit/ae3e222c73eb457ef893aee40469169801af1181
_Note: I know it's a bit older, but that was the build I used.
For build details see below._

Steps to Reproduce:

1. Start Server
2. Join the Server
3. Start talking

Longer Details:

• I did not hear the other users and also did not see any activity (flashing of blue dot)
• Meanwhile the other users could talk to each other.
• They could also hear me.
• Chat was working normal.
• Nothing obvious in the logs (I used the foreground-mode and sadly I did not save the logs)

Workaround:
When I used a different client version (1.3.0), I was able to hear them again.

Expected behavior:
It should be possible to talk across versions 1.3.0 and master.

---

More Details:

• Build options:
  qmake -recursive main.pro CONFIG+="release symbols packaged no-embed-qt-translations bundled-celt no-bundled-opus no-g15 c++11 no-pch no-jackaudio" DEFINES+="MUMBLE_VERSION=master-test PLUGIN_PATH=/usr/lib/mumble NO_UPDATE_CHECK"

• My Sound Server: pulseaudio

• Codec in use was: Opus

---

Further Testing:
Right now I am not able to test a newer master-build etc., but maybe I will do so in a few days.

The intention of this report is to encourage others to also test versions 1.3.1 and master to see whether this problem (also or still) occurs.

---

Note: This is not an ideal report, because:

• I wasn't using the latest master, so maybe this problem is already solved.
• There are other possible sources for the problem (like build-options, Setup etc.) (In this case I am sorry)

Nonetheless I wanted to report it, just in case there might be a regression in master.

[TerryGeng]

Hi. I compiled the newest master version with the build script in scripts/ on macOS and everything works fine. I'd suggest you use the build script directly just in case some build options are not working as you'd expect.

[toby63]

@TerryGeng

and everything works fine

So you can hear users that use a client with version 1.3.0?
Can you give details (like Operating System, Server Version etc.)?

:thinking: Well I guess I will test it again in the coming two weeks.
For now I see these possibilities:

1. It's Linux specific (guess thats unlikely, but not impossible).
2. It was a one-time event (unlikely).
3. It was fixed in newest master.
4. The problem is the server (or better the combination of client and server) (as it was also based on the master from april) and I guess you are on a server with version 1.3.0?
5. You are right and somehow the build options have something to do with it (but that should not be the case and would still be a bug).

[streaps]

Do you know if the audio was transmitted over TCP or UDP?

That only one side hears audio is often a problem in VoIP connections, if the UDP packets in one direction are dropped by the router / NAT is not working properly.

But the Mumble client should switch to TCP automatically, if it doesn't receive any UDP packets.

Have you tried loopback mode?

[toby63]

@streaps

TCP or UDP?

Both TCP and UDP ports were clear and unblocked.
But I don't have detailed logging information and did not use any network analysing tools (yet), so I can't say for sure.

Have you tried loopback mode?

If you mean the loopback in audio config, yes, it was working well.
Update: :thinking: Guess you mean something different.

It is all a bit mysterious;
normally I would have done further testing before reporting, but I thought, maybe this is a more serious regression and it might be better to report it right then.

[TerryGeng]

@toby63

Can you give details (like Operating System, Server Version etc.)?

I'm using macOS 10.13.6, server version 1.3.0.
Mac use CoreAudio as its audio backend. That could be part of the problem as well.

[streaps]

@toby63 If you click on the i right beneath the globe symbol you should see some infos about UDP.

And I meant the loopback option in the audio settings. If you can hear yourself, you should also receive audio from others. So yes, if that was working, it is a bit mysterious.

I did not hear the other users and also did not see any activity (flashing of blue dot)

question to the experts: does this mean that there are no incoming audio packets from the remote user? or what does trigger the flashing?

[vimpostor]

I had the exact same problem once with the official 1.3.0 release (all clients had the same version running). It went away after a restart.

Similarly, I have used a recent master build on Linux myself while other people were using 1.3.0 and everything worked.

So it's probably some rare bug in Mumble that is still present.

[Krzmbrzl]

question to the experts: does this mean that there are no incoming audio packets from the remote user? or what does trigger the flashing?

The flash is triggered by voice data of that user being played. If it doesn't flash though it could mean that the data packets aren't received by the client or that they have been dropped because Mumble considered them to be invalid :shrug:

[Krzmbrzl]

This could be related to #2064 and in fact if nothing else is found here, I think this might be a duplicate of the linked issue.

[TerryGeng]

question to the experts: does this mean that there are no incoming audio packets from the remote user? or what does trigger the flashing?

To be more specific,
https://github.com/mumble-voip/mumble/blob/1bd7839a04bc3445fb3361ec40667081ecdac9fa/src/mumble/AudioOutputSpeech.cpp#L431

Which is inside the prepareSampleBuffer function. This function will be called when the system audio output callback (mix function in AudioOutput) is called to fetch the audio data for playing.

Audio is added to the buffer when received by ServerHandler, whether TCP packets or UDP packets are received.

To check if packets are received, you can write some log in
https://github.com/mumble-voip/mumble/blob/2504f97680f1b8cae6b0878b9156272574063d61/src/mumble/ServerHandler.cpp#L239-L253

Other possibilities include the audio callback is not properly set up so it is not called. Which can be verified by insert some log in
https://github.com/mumble-voip/mumble/blob/40f2abf81e8e9632c3307d6d5f93d5c3284602b7/src/mumble/AudioOutput.cpp#L365-L376

The way to write logs can be traditional printf or Qt-style qWarning. I think you can have a try,

[toby63]

I did another test:
I used a container to simulate a second user with client version 1.3.0 who would send audio (I used a null-sink in pulseaudio and played recorded audio through it)
This time everything worked fine :thinking:.

This is of course not a perfect test-scenario, because it was on the same computer, but nontheless there were two clients who communicated over a server.

@Krzmbrzl
I guess you are right with #2064 .

Can we assume that you already included @TerryGeng's suggestions (here: https://github.com/mumble-voip/mumble/issues/4223#issuecomment-636494515) in your special build https://github.com/Krzmbrzl/mumble/tree/debug-server-audio-distribution ?

[Krzmbrzl]

I did include a lot of log statements (not entirely sure where exactly anymore though), yes.
Our latest insights seemed to indicate though that the packets don't even reach the client

[toby63]

I am not so informed about this issue, but the first part reads something about a qt bug, I guess it's this one: https://bugreports.qt.io/browse/QTBUG-46552
It shouldn't hit me, because I use Qt version 5.12.5.
So this problem seems to be a different one.

I also read about https://github.com/mumble-voip/mumble/issues/1968 , so did you try forcing tcp mode with @nab-os ?

[Krzmbrzl]

No we did not try that yet. I also never really read through the whole issue you linked tbh as from the title I expected only pings to be affected and not the voice communication... :thinking:

[streaps]

@toby63 have you tried forcing TCP mode?

I'm not sure how this problem could caused by the behaviour described in #1968. If the client didn't receive UDP packets, it shouldn't receive UDP ping replies and should switch to TCP. The problem described was that the client has to send an UDP audio packet even if no audio is transmitted.

I don't know if it's possible that UDP pings are received, but no UDP audio packets are received or the packets cannot be decoded (encryption or Opus).

Is the client sending UDP pings all the time or only in the beginning or when it did fall back to TCP tunnelling.

[Krzmbrzl]

Is the client sending UDP pings all the time or only in the beginning or when it did fall back to TCP tunnelling.

Afaik the pings are sent continuously

[toby63]

@streaps

have you tried forcing TCP mode?

No, but I also only had this problem once by now.
If I experience it again, I will try that method.

I'm not sure how this problem could [be] caused by the behaviour described in #1968

I only read the issues and thought that we should give it a try.
If it works the problem has something to do with the UDP implementation.
If it doesn't work, a different solution needs to be found.

I wonder whether it's only a problem in mumble or once again in Qt :thinking:.
But there should be bug reports over at Qt or at least in other Qt-based applications.

[Krzmbrzl]

From the symptoms it seems to me that this is a duplicate of #2064 after all. Therefore I'll close this issue.

You are very welcome though to try and debug the problem more in #2064.
If it turns out that this is indeed a separate issue, we can reopen this thread again :)