Mumble creates loud cracking sounds out of nowhere

[bergfried]

Description

According to "Audio Statistics", there sometimes occur short, loud pops, apparently approximating white noise with maximum power (according to the displayed spectrum). These pops also appear on mumble:output_1 in JACK while in Local loopback mode in Mumble, and other users in Mumble can also hear them.

Steps to reproduce

I use Mumble with JACK for both audio input and output, and transmission mode is set to "Continuous". No amplification, noise suppression, echo cancellation etc. is done by Mumble (all turned off). Instead, I use Carla to send the signal from system:capture_1 through two effects, first noise-repellent with a fixed, pre-learned noise profile, and then compress_rms. The result is then fed into Mumble. (According to the "Audio Statistics" in Mumble, this gives me a "Signal-To-Noise ratio" of 00.000 while silent and something easily above 240000000.000 when I start speaking, which is good.)

This setup used to work flawlessly in Mumble 1.3.4.

Mumble version

1.4.0

Mumble component

Client

OS

Linux

Reproducible?

Yes

Additional information

I tried to identify the source of these cracks by feeding the same signal that I feed into Mumble into other applications. As it turns out, all other JACK applications fail to detect these cracks. Thus, apparently, Mumble creates them all by itself! Then, I tried to capture both the input and the output side of Mumble in a file, using jack_capture. (This is surprisingly difficult because as soon as I switch "Loopback Test" mode from None to Local and apply these changes, the mumble JACK client disappears and then reappears, losing all its previous connections in the process.)

Using Audacity to inspect the resulting file, I could confirm my hypothesis so far: The output appears to be white noise, extremely loud for quite exactly either 512 or 1024 samples, each time surrounded by much softer "tails" (which might be artefacts of some signal processing, or compression artefacts introduced by Mumble), but without any apparent input signal that might have caused it, or any reason why the output should be that loud.

Then, I bypassed Carla and fed the pre-recorded signal that came out of Carla earlier (and might have triggered this issue) directly into Mumble instead, but then, there were no pops or any indication of them happening in the "Audio Statistics" even though Mumble did produce pops during the recording earlier.

Then, I captured the original signal coming from system:capture_1 while I also fed it into Carla simultaneously, which then fed the processed signal into Mumble. Afterwards, I fed that same signal I just recorded into Carla, effectively replacing system:capture_1 as input. Again, there was no indication of pops occuring, despite Mumble being presented the exact same input signal (if Audacity does not introduce changes by itself, that is, but attempts with mpv where also unsuccessful).

If I connect system:capture_1 with mumble:input directly, bypassing all of Carla, everything seems to work fine so far in both 1.3.4 and 1.4.0, but then everything is noisy and the SNR is around 01.000 while silent, and I need to shout to get it somewhere near 500.000.

Note that there were no xruns occuring in JACK during experimentation.

(Just a hunch, but I suspect some numerical issues whenever SNR or the noise spectrum as measured by Mumble is close to zero.)

Relevant log output

No response

Screenshots

Note: All screenshots are independent of each other, not necessarily displaying the same signal.

When it happens in Mumble:

Audacity displaying pre-processed input at the top and the corresponding (and also slightly but insignificantly post-processed) output at the bottom. Genuine input is visible at the left, two spurious pops are visible at the output on the right without any apparent corresponding input:

Detail of a spurious output signal. Note that the highlighted part encompasses exactly 1024 samples and also matches the loudest part of it:

[Krzmbrzl]

Hm... we had reports of RNNoise causing some crackling but you said you are not using noise suppression inside of Mumble...

Did you check whether the issue persist without using Carla at all?

[bergfried]

Yes, I did. Just search for "bypassing all of Carla" in the original post. EDIT: While we are at it: I also noticed the RNNoise-related posts earlier, so I triple-checked my Mumble settings. Keeping Mumble's noise suppression turned off is necessary for me because Mumble constantly relearns the noise profile, which does not work well with singing and the like.

[Krzmbrzl]

Ah yes indeed, my bad.

Could you try whether you can reproduce the issue when using push to talk or continous mode?

[bergfried]

As I wrote in my original post, the issue is present in "Continuous" mode. However, after a lot more testing, it looks like transmission mode does not seem to matter at all. You can even be on "Push to talk", do not press the PTT button and be muted and deafened all at the same time, and the issue can still be triggered. More things I noticed:

• It is apparently easier to trigger the issue in a less noisy environment (e.g. during the night, were it easily happens several times in a few minutes), and more difficult to trigger in a noisy environment (e.g. at daytime, where it only happens like once within half an hour). This is in line with the observation that, given noisy input straight from system:capture_1, it seems to not happen at all, not even at night.
• However, at least once (and only once so far!), it happened with a noticable low-frequency noise floor already present (as measured by Mumble, and after pre-processing in Carla), see this screenshot:

• I initially noticed this issue accidentally during a voice chat with another user who complained about the pops he was receiving. This, combined with the low-frequency noise floor example above, indicates that the issue is less related to amplitude and more related to SNR, which is strange because, given my Mumble configuration, SNR should not matter at all, I think.
• I do not know much about the inner workings of JACK, but if it is related to JACK, it might have something to do with trying to process some input buffer that is not yet ready, or off-by-one-errors while trying to point into a buffer. However, if that were the case, the issue should be much more obvious, and it does not explain why the issue seems to depend on input noise (or lack thereof) more than anything else.
• Speaking of which, I noticed that whenever I have jack_capture running, the pops seem to occur less often, even if the capturing bypasses Carla while the input to Mumble goes through Carla! Shortly after I stop capturing, the pops become more frequent again. My hypothesis is that the capturing alone creates some extra noise (CPU fan, electronics and such) which might be inaudible to humans but enough to please Mumble.

Or maybe it is somehow related to JACK.

I kept experimenting until I managed to create a demo file that I could plug into mumble:input and the issue would become apparent. Not perfectly predictable, but at around the same parts in the demo file, you would get significantly more cracking sounds than at other parts. Nice! However, I tried to reduce dependencies, so I unplugged the mumble:output_* ports from Carla (I normally process those signals as well before it goes to hardware ports) and connected them with system:playback_* directly. As soon as I did that, the issue disappeared! And the more I tried to recreate the same setup with Mumble, Carla and JACK, the less pronunced it became each time I unplugged mumble:output_* from Carla. At the end, I could not reproduce the issue with the demo file anymore, even with mumble:output_* connected to Carla. (Or maybe it was just a coincidence, as it appears to me now.) Restarting Mumble, as I did several times throughout experimentation, did not help either.

So, I restarted JACK. And then, I could reproduce the issue again with said demo file.

Maybe it has something to do with Carla? But how should Carla have an influence here, even if the Mumble process in question never connected to it? Also, there are no issues with 1.3.4, so it is probably specific to 1.4.0. Or 1.4.230, as it reads now in my setup.

I use a buffer size of 512 in JACK, that's why I am not surprised to see this issue involving cracking sounds for that long (or non-trivial multiples of it). Or maybe it's just because some Mumble-related signal processing involves these numbers, think FFT, who knows. So, maybe it has something to do with DSP load? Nope, I also tried this by adding rubberband-pitchshifter-stereo to Carla and shift pitch up by several octaves, along with more stuff, connections and whatnot. DSP load at 67 % but still no readily observable effect. Trying to put stress on CPU, load goes up like crazy, every other application becomes visibly less responsive, but DSP in JACK runs smoothly as always, not a single xrun either. And no effect on the cracking issue, of course. Turning off realtime capabilities in JACK had no significant effect either.

After several more hours of experimenting now, the closest-to-minimum way of reproducing this issue I could find so far is this (with possible some more unknown assumptions, so it's a bit sketchy):

• mumble:input is connected to a "suitably" soft-but-still-noisy input (might be pre-recorded noise via mpv). No Carla necessary on the input side.
• At least one of mumble:output_* is connected to Carla. The actual effect plugin in Carla does not seem to matter, it can even be turned off. However, something other than Carla does not seem to be sufficient.
• The issue seems to be most pronounced just after connecting mumble:output_* to Carla. Also, this should be the only client mumble:output_* is connected to, although this is not required. Thus, if you cannot observe anything after 30 seconds or so, just reconnect to Carla or even restart Mumble.
• As described earlier, you can be "Mute Self" and "Deafen Self" in Mumble, the issue will still be visible in "Audio Statistics".

I wonder whether it is somehow related to #3826, maybe something involving synchronization (memory corruption) issues or floating-point conversion (numerical) issues or something. Is there an easy way to build a 1.4.230 but with #3826 reverted on Arch Linux? Like a PKGBUILD including necessary patches?

Any (other) ideas?

[bergfried]

I just closed the "Audio Statistics" window, and the entire graphical environment crashed immediately. This is now the second time that something like this happened during experimenting with 1.4.230, and it only happend during this time.

[Krzmbrzl]

Uff - what a strange issue.

You can of course always clone the repo and then just use git to revert the commit(s) in question before building Mumble :thinking:

[bergfried]

For the record, I did not experience this behavior for years now, which might be also due to a hardware upgrade in the meantime which turns the whole thing irreproducible. Closing.

[Krzmbrzl]

Thanks for the update :+1: