search

mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.32k stars 1.11k forks source link

Specific users cut out with no clear pattern, majority have no problem #3350

Open mgalvey opened 6 years ago

mgalvey commented 6 years ago

I'm experiencing an issue where two of the users on my server cut out, seemingly with no pattern, every once in a while. The disturbance usually lasts less than a second and is accompanied by a "pop", similar to what you'd hear when you hit the mute switch built into some microphones.

This problem occurs only for me, and is not audible in recordings made by my mumble client. I've included as much information as I could gather below, and am willing to work with the users I mentioned (mostly the first one, second is flaky) to perform additional troubleshooting and info gathering.

Mumble and system info

Me (user experiencing the cutouts):
- Fedora 27 x64
- Mumble self-built from the latest (at the time) master: 765f7807477de520b241d7228fb41ed869bc2029, using the bundled codecs and the following options: CONFIG+=no-g15 CONFIG+=no-server CONFIG+=optimize CONFIG+=no-oss
- MATE Desktop Environment
- Tried both ALSA and PulseAudio as output systems, no positional audio

First user exhibiting the problem:
- Windows 7 SP1
- Mumble 1.3.0~2586~g894ade2~snapshot
- Using mainboard-integrated audio: Realtek ALC892 8-Channel High Definition Audio CODEC

Second user exhibiting the problem:
- Windows (I believe 7, but not certain)
- Mumble 1.2.19
- Last I heard, using a USB mixer board

First user NOT exhibiting problem:
- Windows 7
- Mumble 2.1.17
- Using a USB audio interface: Art USB Dual Pre powered by "BurrBrown from Texas Instruments USB AUDIO  CODEC"

Second user NOT exhibiting problem:
- Windows 10
- Mumble 2.1.19
- Using an unspecified XLR -> USB adapter

Finally, I've been able to capture some output that happens sporadically in my developer console. These messages seem to show up pretty consistently when the problem occurs, but they also show up at other times as well. They DON'T show up at all when I'm using PulseAudio directly rather than through ALSA.

<W>2018-02-26 20:48:08.807 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.818 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.826 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.833 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.840 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.848 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.855 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.863 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.871 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.878 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.889 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.899 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.911 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.921 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.934 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.945 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:08.957 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:28.545 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:28.557 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:28.566 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe
<W>2018-02-26 20:48:31.722 ALSAAudio: Non-critical: avail = snd_pcm_avail_update(pcm_handle): Broken pipe

As a final thought, the only thing that sticks out to me is that both users exhibiting this problem are in geographically similar locations, and their pings are significantly different from the users who show no problems; 70-100 for the problem users, and 30-45 for the "normal" ones.

opatut commented 3 years ago

We have a similar situation here, let's call us persons A, B and C.

A periodically stops hearing B. C is also in the channel and always hears A and B. B also hears A and C all the time.

We've noticed that A is getting "Broken pipe" reports like above. A is using Linux with Alsa directly.

B and C have no issues, they are using different Linux distributions, but with PulseAudio.

B, who sometimes cuts out for A, has their "Quality" setting on highest (96kb/s), while C has it at 40kb/s. Lowering the quality on B's side solves the problem for A.

Edit: All of us use 1.3.4.

Krzmbrzl commented 3 years ago

B, who sometimes cuts out for A, has their "Quality" setting on highest (96kb/s), while C has it at 40kb/s. Lowering the quality on B's side solves the problem for A.

So that is interesting. This would suggest that ALSA has a problem with higher bitrates. Was A perhaps able to switch to PulseAudio to check whether the problem persists? :thinking: Or is perhaps C able to try out ALSA?

shaoran commented 3 years ago

I'm 'A', I am the only that has sees a lots of broken pipe. I run a Gentoo Linux without pulseaudio, so it connected directly to ALSA.

Krzmbrzl commented 3 years ago

@shaoran A quick google search brought up http://wiki.rivendellaudio.org/index.php/Garbled_audio,_alsa_error_32:_Broken_pipe,_Xrun_errors where it is suggested to tweak some buffer size. Any chance you could try that out?

opatut commented 3 years ago

We've moved C to ALSA and will check. However, it looks like they are not experiencing issues for now. A has the highest power machine so it's probably not decoding speed or something like that. A also has best ping. This is weird. A also has played around with their "Jitter buffer" and "Output delay" options, to no success :(

shaoran commented 3 years ago

@shaoran A quick google search brought up http://wiki.rivendellaudio.org/index.php/Garbled_audio,_alsa_error_32:_Broken_pipe,_Xrun_errors where it is suggested to tweak some buffer size. Any chance you could try that out?

But this is rivendell configuration, this PeriodQuantity variable seems to be a rinvendel specific flag, so I don't know how to change that.

Krzmbrzl commented 3 years ago

Ah okay. Maybe this is something we have to do when opening ALSA? :thinking:

@davidebeatrici do you know something about that?

shaoran commented 3 years ago

I could try pulseaudio, but that will be a pain, because I would have to reconfigure my whole system (as I "banned" pulseaudio from my system) and re-enabling pulseaudio would mean recompiling some stuff. I'd rather not do that.

Krzmbrzl commented 3 years ago

You could also try to reproduce the issue in a VM and then mess with the VM instead.

shaoran commented 3 years ago

Yes, I'll try doing that, but I will do it later.

Krzmbrzl commented 3 years ago

@shaoran were you able to make any progress on this?

shaoran commented 3 years ago

@Krzmbrzl I'm sorry, I haven't had the time to deal with it, because at the moment I have a few deadlines for this and next week, but I haven't forgotten about it.

shaoran commented 3 years ago

So, I have news about my test. On last Sunday (it was raining the whole day, so I had time for this), I setup a Virtualbox VM with Gentoo and the same kernel config (the audio part) as with my system. In the VM I even selected Intel HD audio to match the same linux driver. I also used the same toolchain with the same CFLAGS, so the build system should be the same as my normal system, only inside a VM. And no Pulseaudio, ALSA only. Basically, same settings.

Here I also get the broken pipe messages, I even get so many that I cannot even pass the configuration screen when you start mumble for the first time. I copied ~/.config/Mumble (which I removed again for the export) from my system and I could not hear people speaking while I saw a constant stream of broken pipe messages. And I made sure that audio is working, on the home directory there is wav file, if you play it back with mplayer or aplay, then you get sound. I even installed chrome and went to youtube, I got audio from youtube. I could also watch youtube and execute mplayer at the same time, no problem. So audio is working.

So I made an export of the VM for you to download. https://elecciones-ecuador.shaorandev.org/owncloud/index.php/s/zbCAepFmk7r15Gj the password for the file is mumble.

$ md5sum Mumble\ test.ova 
5c9504c4c30970e3d8c79f69971ef57e  Mumble test.ova

In the VM, there are two users: root & mumble. The password for the root user is mumble-root, the password for the mumble user is mumble. sudo is enabled. The default resolution 800x600 but when you log in, it changes to 1680x1050 but you can maximize the window of the host vm and then in the guest open a terminal and execute VBoxClient-all. That will make the screen of the guest go black for around 10 seconds (or more) but then the desktop size will match your host window size.

If you want to test it, please download the VM. In about a week I'll remove the file from the server. Please let me know if you need more information.

Krzmbrzl commented 3 years ago

I have downloaded the image, but I won't have the time to look into this (not any time soon anyways). So if someone wants to look into this, let me know and I can provide you with the file.