search

mumble-voip / mumble

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

Audio output is picked up as input #5577

Open Krzmbrzl opened 2 years ago

Krzmbrzl commented 2 years ago

Description

When having Mumble open, it often (always?) happens that Mumble is somehow picking up the audio output (general system output - this could be music playing or someone speaking to you via Mumble. Really any audio output at all) as audio input. This manifests in the following way:

  1. When you are currently transmitting audio, the picked up audio will become part of your transmitted audio (potentially distorted though - presumably by means of echo cancellation and noise suppression)
  2. When you have VAD (voice activation) enabled, the audio output can actually trigger the threshold and cause you to start transmitting. If not, you will at least see the input-meter in the audio input settings jump around with the played back audio.

At first glance this looks like regular echo, but this is not what is happening, since it also happens when using a headset where the audio is played back through the headset and thus the microphone never gets to hear the audio output. And just to be sure, this also works when the microphone is explicitly muted (not within Mumble but with the headset itself). And as if that was not enough, the effect can also be reproduced by not having any kind of microphone connected to your computer in the first place.

Steps to reproduce

  1. Go to audio input settings
  2. Enable VAD mode and hit Apply
  3. Start playing some music in an external player (completely unrelated to Mumble) and observe the input-meter in the settings page to start picking up the signal

Mumble version

1.4.230 (probably has existed in earlier 1.4.x versions as well - whether it also occurred prior to 1.4 is unknown at this point)

Mumble component

Client

OS

Linux

Reproducible?

Mostly - not always, but often enough, to call it reproducible

Additional information

While I am using Linux most of the time, my personal experience as well as received reports indicate that this phenomenon is present on Windows as well.

Related: #4612

Relevant log output

No response

Screenshots

No response

Krzmbrzl commented 2 years ago

@TerryGeng could you test whether you can also reproduce this on macOS?

TerryGeng commented 2 years ago

I have never encountered this since https://github.com/mumble-voip/mumble/pull/4814.

If I recall correctly, before this PR, even if the Mumble took the output as input, there would be no sound transmitted into Mumble.

4814 also addressed a problem: In the past, if I was using an audio interface with both input and output channels, Mumble could not correctly identify it as an input device. I suspect the device in question also has both input and output but the user was not aware of it. Anyway, it seems very unlikely you can get any sound from a misidentified output device, otherwise the echo cancellation of macOS shouldn't be that painful to implement.

davidebeatrici commented 2 years ago

May be related to #5302, as at this point it's almost certainly a memory corruption.

Krzmbrzl commented 2 years ago

I don't think these are related, since I can fairly reliably reproduce this issue here whereas I can't reproduce the crash

Hartmnt commented 2 years ago

And as if that was not enough, the effect can also be reproduced by not having any kind of microphone connected to your computer in the first place.

Interesting. Some users I know and I have been experiencing this in some way or another for years all using headsets. I have always 100% believed this happened hardware-side because of bad shielding on 3.5mm jacks on most mainboards (especially if they have front 3.5mm connectors as they are usually really garbage) or on cheap headset cords/plugs. Therefore I have never considered it to be a Mumble bug. I am also almost certain this happened sometimes using TS3 or Discord but I don't clearly remember. In the past we have usually worked around this by adjusting the right settings such as recording volume, echo cancellation and voice activity thresholds and it worked almost always fine.

Now when I read this sentence above I got curious. This would clearly indicate a bug in Mumble, or wouldn't it? I opened the Mumble settings without a headset connected and saw the voice meter peaking - not over my activation limit, but clearly peaking. I set the transmit mode to continuous and recorded the output. Turns out it is just noise that comes and goes in waves but with the slightest hint of something that was actually playing at that time, not enough to recognize it though and it would certainly be silenced by noise reduction, if I was to speak.

However, I remembered that I use 3.5mm jack extension cords, so technically there is still something plugged into my mainboards soundcard even though the actual headset is not. So the next logical step was to unplug the cords as well. Now I was getting a threshold triggering signal on the voice meter. BUT, after digging through WebRTC stuff on Linux the last couple of days, it came to my mind that PulseAudio (and maybe Pipewire?) has the weird default behavior of falling back to ANY monitor device as an input device, IF there is no recording device plugged in. So I was getting the Monitor of Built-in Audio Analog Stereo implicitly as recording device in Mumble, which could easily be missed if you weren't aware of this behavior. So as the last step, I manually switched the Mumble recording device in PulseAudio back to the (unplugged) microphone. I still got some movement of the voice activation meter, but this time it was the exact same as in the PulseAudio GUI. It has probably nothing to do with Mumble. I hit record and turned the music up and got... complete silence as expected.

What does this mean? I'm not sure. From my perspective it supports the idea that this might be a common hardware problem as the extension cords could pick up/transmit interference. Maybe someone with an USB headset could confirm or refute that. As it stands this "bug" might be more delicate to explore than "just a bug in Mumble". It might also be a hardware quirk or sound system bug depending on the configuration.

@Krzmbrzl when you unplugged your microphone were you 100% sure PulseAudio or Pipewire wasn't suddenly using a monitor as recording device for Mumble? That would at least explain your observation without a mic plugged in.

diftucs commented 2 years ago

Both me and the one I was talking to when I experienced this bug were using wireless headsets with dongles (not in the same location), so there should be no room for hardware bleeding in my case.

At the time, I could activate their microphone by talking loud enough to go over their threshold and hear myself. This also rules out that the bug is only a simple case of "monitor gets chosen as microphone input" as we could both hear each other while I also heard the echo.

powerjungle commented 2 years ago

I don't think these are related, since I can fairly reliably reproduce this issue here whereas I can't reproduce the crash

@Krzmbrzl On my machine I can reproduce the crash 100% of the time. I know this doesn't help much, but just wanted to mention. :D

Krzmbrzl commented 2 years ago

When you unplugged your microphone were you 100% sure PulseAudio or Pipewire wasn't suddenly using a monitor as recording device for Mumble? That would at least explain your observation without a mic plugged in.

Indeed, that seems to be the case. I didn't expect such a silly behavior. Who wants to feed the monitor of their audio back as input (by default)? :facepalm: As soon as I plugged in my headset (with muted mic), the input meter flattened.

Maybe someone with an USB headset could confirm or refute that.

With my USB headset I now did not get any audio output bleeding into Mumble. However, in the past I have at least seen that someone speaking with me through Mumble did bleed into my input while I was using this very headset. Since the microphone was working, I doubt that this was also caused by PA selecting some monitor as input device :thinking:

I'll have to keep an eye on this, to see if this behavior will show up again :eyes:

benklett commented 2 years ago

I can confirm the problem exists in versions prior to 1.4. on Linux ,version 1.3.4 to be exact. Probably even before that as someone already commented. I cannot notice anything in pavucontrol. The problem only exists in mumble. I noticed it takes a few seconds of output before the feedback starts. It's quite dampened and mostly distorted.

MiSteiner commented 2 years ago

We also experienced this bug & tried various things. Instead of unplugging the mic / headphones (which could theoretically cause mumble to switch the audio device), we completely turned down the gain on the audio interface. The audio bleeding into the mumble input continued even with no physical audio output (& the mic gain set to 0 as well).

Disabling the echo cancellation completely fixed this problem for us.

Can anyone else confirm this?

Krzmbrzl commented 2 years ago

Disabling the echo cancellation completely fixed this problem for us.

That's very interesting. That seems to support my theory that this is related to echo cancellation :eyes:

benklett commented 2 years ago

Disabling the echo cancellation completely fixed this problem for us.

Can anyone else confirm this?

This sadly did not fix it for me.

RichardDastardly commented 2 years ago

Have just upgraded to 1.4 series ( I know ) and have exactly the same problem - I have an Audient ID14 box for headphone/mic use which has three pairs of software outputs & if I use ether the first analog input or the driver's loopback device ( it's basically an input mixer that can feed it's own output channels back in - it doesn't loop back everything unless you tell it to ) and the first audio out pair, I'll get runaway feedback even in the mumble audio wizard. Stepping down to the third output paiir just turned the problem into simple echo, but the problem persists in other voice clients like Discord as long as Mumble is running, even if it's not being actively used . I've used the same gear with 1.3, so I'm at a slight loss where to start other than reinstalling 1.3 & hoping. Generic mic out is fine, Discord is as fine as discord ever gets provided Mumble is closed.

I've tried disabling all echo cancellation/noise reduction ( I usually turn them off anyway ) to no avail.

Tremolo4 commented 2 years ago

And as if that was not enough, the effect can also be reproduced by not having any kind of microphone connected to your computer in the first place.

I used to have this problem a few years back but not specific to Mumble. People would hear my music or any other sound played on the PC, even when no microphone and no speaker was connected at all.

I eventually traced it to the front panel of my PC case. After disconnecting the Front Panel from the mainboard (and using the jacks on the back panel instead), the problem disappeared. So apparently the case's front panel has some insufficient shielding such that the output jack bleeds into the mic jack. The internal audio cable is called "Intel HD"/"Azalia" or "AC97".

That said. the echo cancellation not working correctly sounds like another reasonable explanation for some people at least.

Hartmnt commented 2 years ago

And as if that was not enough, the effect can also be reproduced by not having any kind of microphone connected to your computer in the first place.

I used to have this problem a few years back but not specific to Mumble. People would hear my music or any other sound played on the PC, even when no microphone and no speaker was connected at all.

I eventually traced it to the front panel of my PC case. After disconnecting the Front Panel from the mainboard (and using the jacks on the back panel instead), the problem disappeared. So apparently the case's front panel has some insufficient shielding such that the output jack bleeds into the mic jack. The internal audio cable is called "Intel HD"/"Azalia" or "AC97".

Yes, this is also my experience as described in my earlier post. However, as people with USB headsets are seemingly also suffering from this problem, there might be a few different causes.

walmartshopper commented 10 months ago

I have been fighting with this recently. I have a setup where I'm using mumble for Radio over IP to link two remote radios. Each endpoint is a Debian 12 laptop running the flatpak version of Mumble. Each laptop has a Signalink USB audio interface. The Signalink USB presents itself to the laptop as a standard USB audio interface, however the input and output are hooked up to a radio. So when mumble outputs audio, it gets transmitted over the radio. When the radio is receiving, that is the input for mumble, which then gets transmitted at the other endpoint. I wanted it to be an always-on type of setup. Everything works initially, but then this issue appears after mumble has been running for a while (a day or two?). In our case it has the potential to start an endless transmit loop on the radio. The problem is that this issue appears on both mumble laptops. So laptop 1 sends audio to laptop 2. Laptop 2 treats that as input and sends it back to laptop 1. Laptop 1 treats that as input and sends it back to laptop 2, and so on, which creates an endless feedback loop. This all gets transmitted over the radio until I turn off the Signalink. If I close and re-open mumble on both laptops, the issue goes away. However since I know it will come back eventually, I can't really trust mumble running 24/7 because I can't risk starting a feedback loop over the radio. Both endpoints are using PipeWire for audio and the Echo Cancellation option in mumble is grayed out on the Disabled option.

I am wondering if it has something to do with the USB audio interface resetting or temporarily falling off the USB bus which makes the monitor input kick in, although I don't see any USB-related messages in syslog. I'm going to look into completely disabling the monitor inputs and see if that fixes it, but if not I might have to try switching to teamspeak.