Discord to Mumble broken

[stryan]

I'm having a lot of issues getting voice from Discord transmitted over to Mumble. Occasionally it seems to work (especially if I set it up from a clean slate i.e. just restarted the program, no one in either Discord or Mumble when the bridge starts) but otherwise nothing is transmitted over.

From my own debugging efforts, it appears the problem occurs around here: https://github.com/Stieneee/mumble-discord-bridge/blob/d9d30929ffa47b69e097506dc6966c3636afb71f/discord.go#L158-L159

I think the second line (L159) is blocking the thread; I'm assuming when it's being consumed by fromDiscordMixer. Commenting either line out allows for audio to be transmitted, though in very poor, cut up quality.

Mumble->Discord transmission works fine. Any advice would be appreciated or if you need more details please let me know. I can recreate the issue on both a Raspberry Pi 4 and my x86-64 desktop.

[Stieneee]

Hey stryan,

Interesting. That channel is buffered so the line should be non-blocking (unless the buffer is full). Cutting out one of the lines would drop half the audio from a 20ms packet which would produce some low-quality audio. I had more difficulties with the mixer that the data travels through next.

I created a branch with some code that should help us get a better understanding of what is going on. https://github.com/Stieneee/mumble-discord-bridge/commit/f8518176d53aa7e08b5049f3a5caa2813c782a2a

Anything interesting in the logs?

[stryan]

So naturally once I've added those logging lines I can not re-create the issue off hand (and removing them again doesn't cause it either). I'll try running the bridge for a while and see if it happens again; could have been an issue yesterday with Discords gateway.

[Stieneee]

Well, at least it's working. I do believe there exists an edge case with discord that is not being handled. I will leave this issue open and if you come across anything interesting please feel free to share. There are several improvements I would like to make to the bridge when I can find the time. Maybe I will stumble upon the issue. Also, I noticed you committed some of your debugging any improvements worth committing back?

[stryan]

Sure, I'll keep an eye out for things; been running for a few hours now with multiple restarts and about 5 people cross both discord and mumble with no problems besides some messages about filling up the mumble buffer.

As for my fork, most of the debugging improvements are low quality and I'll probably take them out. I'm basically just duck taping features I want onto it (manually triggering the link, showing how many people are online, etc). Once I get it cleaned up and not garbage hacks I'll PR and you can add what you think is fit :)

[stryan]

Whatever it is, it's happening again today: if I try to run the bridge without the debug section I can't hear anything from Discord->Mumble. With the debug section (and it being able to drop packets from discord) it works fine though. Here's the log: https://gist.github.com/stryan/3b967c3be87ad802333c294c36434ec6

That big fromDiscordMap section was immediately when the bot joined the voice channel. Looks like something is happening on the initial voice connection that ends up filling the buffer. As long as it can get past that part though it works fine

It's also possible it's something to do with how I set up my bot user if you can't recreate the issue; I'm not super familiar with how Discord bots/etc work.

[Stieneee]

I tried playing around with it on my end but can seem to reproduce your issue. I have a feeling it's related to your setup (hardware or network). When I develop this, it's on some reasonably powerful hardware with a stable and low latency network setup. When it runs, it's on a DO box shared with my mumble server. I may try to experiment with a PI this week.

The many fromDiscordMap drops at the start of your log could be related to the time it takes to establish the mumble connection. Since discord establishes the connection first, a slow mumble setup might be causing that initial load. There may be some other buffer filling up that being pushed into the fromDiscordMap.

I wonder if "The toMumble buffer full Dropping packet" in your log suggests that the goroutine that needs to clear the toMumble unbuffered channel is not firing at least once every 10ms. I don't have an understanding of the code consuming the toMumble buffer.

I don't think we need to think of the issue-4 branch as debugging code. The reality is we should really be handling audio packets as a best-effort approach and not blocking on any of the goroutines.

To confirm your last comment with the issue-4 branch, your bridge is fine? Are you running the bridge on the same machine as mumble, or is a network in between?

[stryan]

Ah, that does make sense. Sure, it's fully possible then I'm running into a bandwidth issue on the Pi. It's running both the bridge and the Mumble server so latency is low, but it is of course a Pi so not the beefyiest hardware (and it is running other services as well). It's also possibly an issue with my Mumble setup.I'll see if I can wrangle up something a bit stronger in the near future and test it out in a clean environment.

Sure, I was only referring to it as debugging code to differentiate; I think letting it drop packets both ways is the right thing to do regardless (as you said, best effort approach). I've integrated that into my own fork already and have had zero problems of this nature since so once issue-4 branch is merged I'd say this is pretty low priority.

[stryan]

Sorry to comment on a closed issue, but I figured out what the fromDiscordMap drops was caused by. I use the LDAPAuthenticator plugin with Mumble and while the plugin runs on the same server as Mumble, the LDAP server is actual a continent away, resulting in probably about a 700ms delay between connecting to the Mumble server and being able to actually join it while auth happens. During this delay is when the fromDiscordMap packet drops are happening.

So the issue is related to my setup and it's otherwise not a problem, though it might warrant a note in the README somewhere. I don't know how many people use Mumble with a seperate auth system but I'd imagine it's not that uncommon.

[Stieneee]

Interesting, thanks for the additional information. Feel free to add a Readme update you feel is appropriate.