I really wish Discord would implement an audio compressor (or if they use one, make it much more aggressive) for voice chat. For example, Mumble doesn't require manually adjusting anyone's volume - instead, it uses a compressor to automatically normalize volumes for everyone.
In contrast, Discord has a volume slider that I end up having to adjust for most people. That requires manual tweaking, often while I'm playing a game, and isn't future-proof; just the other day, one of my friends changed his microphone setup and was extremely loud (I had him at 200% when in the new setup he should've been at about 75%).
This is really my only complaint with Discord's VOIP functionality. It is a major step backward from Mumble. (Also, for some reason the Discord community mostly uses voice activated mic instead of push-to-talk, but I don't think that's Discord's fault.)
The only reason you'd want to use push to talk is either you have a lot of people in the channel, you have a loud background or you don't want people hearing stuff not designated for the discord voice (if you're streaming, have irl people in the same room - that kinda stuff)
I couldn't disagree more. Having an open mic setup for gaming is both insane and completely inconsiderate to everyone else in the channel/group.
It's hard not to personally judge people that join a group, whether that's a friend of a friend, someone looking to try out, public LFG lobbies, etc and you can immediately tell they have an open mic configuration. It's maddening.
Breathing, keyboard smashing, mouse clicking, background noise, eating, or exasperated whining every time you die/lose are all annoyances you push on the rest of the channel/group with an open mic configuration. At best it's an annoyance. At worst it's actively disrupting people's game play and team communication.
For the love of all that is decent with humanity, use push to talk.
Personally, I hate the sound of people chewing and smacking their lips directly in my ear as they work their way through their 'fresh that afternoon' gas station nachos.
I can't tell you how many times I've ran into users who just cannot get their sensitivity right. So in turn, you end up with a ton of people coughing, sneezing, talking to others, fans, and insert your other favorite background noise. Most users just don't care to set it up right, and it's impossible to get them to adjust it (unless you have some type of Discord Mod / Admin privs on the server at the time to force them to fix it). Otherwise, you have a bunch of users who have to put up with Joe-Schmoe chewing away on his mic.
It's why the Discord servers I'm in 100% completely enforce PTT, zero voice activation allowed.
It's not a sane default for people gaming with mouse/mechanical keyboard. The voice activation can (in general) be set not to have squad breathing and chewing in your ear - but you'll hear every Crack of desperate mouse movement...
It might be better with people using Xbox controllers.
Which is also extremely common. Fans, open windows, keyboard, neighbors yelling, etc.
you don't want people hearing stuff not designated for the
Like the fact you're a goddamn mouth breather. Fuck I refuse to join most discords because most the time I have to hear people mouth breath into their mics.
I think you outlined several major reasons to use push to talk. I exclusively use push to talk, specifically so I am not that guy in raid with an open mic, breathing heavy, with police sirens wailing in the background.
Eh we raided Mythics with 25 where most people had voice activation. Was perfectly fine.
I think it's more about who you're playing with, if you are good friends with the people that you are on voice with, chances are you're quite alike and considerate to each other.
Even for Overwatch in a group with 2-3 friends I’d much rather have them use PTT because a lot of people are keyboard-smashing typists who can’t set the mic transmit threshold right.
I think that's exactly it, as well as the comparative twitchiness of the game. You don't have time to fiddle with an extra button in something like Overwatch while you can probably exchange a couple of emails and check twitter during a single FF14 GCD.
I used TeamSpeak for a long time but when my group switched to Discord there have been a litany of audio problems. My favorite is people will complain about an intermittent hiss that only stops when I talk. The hiss ends even after I've finished transmitting, and I'm not transmitting the hiss (it happens even when I'm not connected to the audio chat.)
I don't find this to be the case. I have played several games on several servers, including 40 and 50 person channels, and I have never manually adjusted volume. The only adjustment I make is to mute myself so everyone else can't hear me yell at football.
For those interested in open source/decentralized alternatives to Slack/Discord/etc, I've had a pretty great experience with both the voice and video integrated into Riot.im[0] (uses Matrix protocol[1] for chat, and Jitsi[2] for voice/video).
I've said before that I can't really justify nonfree software for something as simple as text chat.
That said, rooms with very large numbers of people trying to communicate with voice/video is one use case where maybe it makes more sense for a commercial product to solve it.
Why is the riot "TRY now" link so damn hidden? Two clicks, one long search here https://riot.im/app/#/home
No private room? Not working without google? Very bad first impression :(
Personally I'm sad that people are going for non-decentralized solutions these days. I thought we aggreed that decentralized is the way to go.
Everyone hosting their own Ventrilo/Mumble/Ts3 servers had the huge advantage that not only one single company got all data everyone produces. Not to mention outages.
They say in the blog post
> Routing all your network traffic through Discord servers also ensures that your IP address is never leaked
They also clearly explain why decentralization doesn't work for large rooms:
> Supporting large group channels (we have seen 1000 people taking turns speaking) requires client-server networking architecture because peer-to-peer networking becomes prohibitively expensive as the number of participants increases.
It's unfortunate, but it's just the truth. The reason we aren't seeing decentralized solutions to the problem that Discord solves is technical. It's not because people don't want it or aren't trying. I just doesn't perform well enough.
> > Routing all your network traffic through Discord servers also ensures that your IP address is never leaked
> Yeah, except to your centralized company servers.
Which most gamers don't care about.
What they do care about, is what follows that sentence: "preventing anyone from finding out your IP address and launching a DDoS attack against you".
Especially for high profile e-sports figures and streamers, that's a very real problem: they want to interact with their fans using chat/voice calls, without giving bad actors the means to DDoS their residential connections (causing disconnects from game matches etc).
That's also why Discord proxies all embedded media from third parties through their own servers (except for some major sites, that are white-listed).
> For clarity, we will use the term “guild” to represent a collection of users and channels — they are called “servers” in the client. The term “server” will instead be used here to describe our backend infrastructure.
I still don't understand why you ever chose the name "server" to refer to something that is many things, but not a server. Guild is a way better name, and doesn't need disclaimers about your self-chosen terminology being confusing.
I believe this is a tradition that has been grandfathered into voice chat apps. Previous ones like Ventrilo have you actually connect to a private server (that someone pays for / hosts).
I second this explanation. Additionally, from a UX perspective, if a user wanted to join your server you had to give them IP/port/pw and they'd type it in manually. So even the users were accustomed to addressing servers. "Server" entered the community lexicon as "the place we chat".
This is most likely the case. Discord's introduction was mainly to pull in the gaming audience using Skype while providing the quality behind Mumble and Ventrillo
Users colloquially call such communities "servers" because Ventrilo and TeamSpeak historically required actual servers for each community. The terminology has stuck. Discord definitely made the correct decision calling them "guilds" internally and "servers" for user-facing material. Nearly every user has always called them servers.
They used to be called Guilds, even in the user-facing client. I'd imagine a conclusion was drawn at some point that the term Guild is far too niche even inside the already niche video gaming community; its really only used in MMORPG-style games.
Agreed. I feel like if I told a non-gamer friends to join my Discord 'guild' I'd get less yesses than if I called it a 'server'. In a way 'server'/'community' feel like much more inclusive terms.
And even in the niche of MMORPG games, it's just one variant of name for the (relatively) permanent groups that players usually organize themselves in. It's rather common in the fantasy/medieval-type MMORPGs where it actually has its origins, but uncommon in pretty much all other themes, especially anything scifi. Eve Online for example calls them "corporations", which is a better fit for a science fiction universe. Anarchy Online just called them "organizations", while Star Trek Online calls them "fleets".
So yes, "guild" is a really bad name for the thing pretty much anyone in the target demographic is used to call "server", whether that thing actually was a physical or logical server or not. "Guilds" also used to have a voice "server" to host their voice chat activity, but they did never equal themselves to their voice server, so even if all games out there called groups of players "guilds", it would still be a really bad choice. Someone at Discord apparently learnt on the job that "naming stuff" is one of the two hardest problems in IT ;-)
I'm a programmer who well knows what a server is to a programmer, but I'm also a gamer and Discord calling its servers servers never seemed weird to me. From the perspective of the user, the term makes sense. The servers have users, those users have permissions, they host files, they host chat, you can install plugins to them.
It would have taken my community a lot longer to switch over from our Teamspeak server [0] and come to Discord if they were called guilds.
We don't play MMOs, aren't very organized, have a very flat hierarchy, (admins, regulars, new users) and don't stick to one game very long.
The word guild comes with too much baggage, and that single word choice would likely mean we'd still be on Teamspeak to this day. I don't think I'm exaggerating that point either.
I never considered "server" a poor name, even knowing that it was probably not one dedicated physical server in reality. It's simply the right nomenclature for the target audience.
[0]: A Teamspeak server is definitely a server as I assume you define them.
Server is the de facto standard terminology that users expect here. Guild would be a horrible name since it comes with a lot of preconceptions, especially for gamers.
Can anyone who works on the discord app explain to me: How am I impacted for having (being part of) let's say 100 server (guilds) on my app versus having 1?
Should I quit the discords that I don't use? I feel like they stay in sync in the background and if I am in 100 servers and they all post say tons of text I will get massive lags.
Does that make sense? Is there a way to prioritize only the server I have active/I am talking in and freeze the rest while im full-screen/in-game/focused?
We've put a lot of work into our clients and our backend to make sure the impact of being on 1 vs 100 guilds is negligible. It helps that most of the folks building Discord are power users in a bunch of servers (so we feel the pain of poorly optimized paths early). Generally if you don't look at a server often it shouldn't effect the performance of the app / bandwidth usage. I think we have some more blog posts in the works regarding some of these topics so look forward to those!
Well, are you ever going to provide a better way to deal with 10+ servers? The left-side server UI is terrible. The icons aren't enough to figure out which server is what and it desperately needs some form of sorting or categorizing (being able to create custom groups of servers, for example per game or any arbitrary list of servers). I end up continuously pruning my list so I don't have more than 10 because it's so bad.
WoW alone forces me to have 1 server per class, then 1 server for every guild I'm associated with. Forget about any other game.
If a guild is completely muted (including @everyone), and I don't open it, do you have a rough estimate of how much resources it uses? In theory, it should be zero, but in practice, does is the server sending me updates about messages even if I'm muted?
I'm pretty sure there isn't a ton of background fetching asides from marking servers as unread, it can take a bit to actually load the messages when you click an inactive server, and it won't have any new messages if you don't have a connection (even if it had a connection when it was sent)
OT:
actually what I always wonder, is how Discord will make money.
I mean they offer this huge free service for everybody (2.6 million concurrent voice users) over 1000 servers that must be a huge GCloud invoice
We don't host our voice servers on google cloud as that's actually really expensive. We rent commodity dedicated servers. Our voice fleet is basically JBOS (just-a-bunch-of-servers). We use really low-spec servers too (4 core - 8 thread xeons @ 4ghz), 8-16gb ram, shitty hard drive (as these servers literally do no IO operations aside from some logging), and have no persistent state.
do you do that much money from nitro? I actually never seen that many adds in discord about nitro and I didn't even knew it exists (i'm using discord for over a year) and I mean we actually migrated from a 10€ teamspeak to discord. while it is unlikely that everybody in my group would buy nitro, I find it amazing that you do not have many adds in your app, not even about your own service. (i mean sometimes there is the update pop up and some messages between the chat messages, but we basically never use that much of the chat anyways...)
They’ve just started a game store. Encouraging integration of their social features into games will allow them to take a healthy bite out of Steam’s pie.
Same thing as WhatsApp. VC pay most of the bills until the network effect has cultivated the userbase to a size attractive for a buy out by a bigger fish.
WhatsApp was bringing in 10M in revenues[1] a year with the .99cent fee. Not selling it wouldn’t have made them billionaires, but it’s certainly fuck you money for a team of 8.
I'd be interested to see how the system works during high-load events. It sounds like if a server gets overloaded, it shuts down and moves the clients to the next non-overloaded server. If the health-check used by the load assignment server is not perfectly tuned, then that failover overloads that server, shutting it down. Eventually you have no servers left.
I suppose that a perfect health check will prevent this, since the failover will assign failover traffic at exactly the level that the new server can successfully handle. But if it's wrong on the other side (rejects connections when capacity actually exists), then compute resources are wasted "just to be safe".
I imagine that estimating capacity is even more difficult since people can join and leave at any time, and the client doesn't send any packets when there is silence. So the load changes based on how talkative people are being (which means your server always crashes during the best parts of whatever you're discussing).
Anyway, I'm wondering how this all compares to the naive strategy of "pick a random server for this channel, if it crashes, bad luck".
Perhaps I can answer some of these questions. We've dealt with scenarios where we've had to fail-over entire data-centers to other regions, or other data-centers within that region. We have a few mitigations in-place for stuff like this.
a) A voice server can sit in multiple different load categories. So it's not "best server by score", but rather "best server out of a pool of servers with a given load factor". The load factor is one of ":verylow | :low | :medium | :high | :veryhigh | :extremelyhigh | :full" When looking for a server, we have an index of "best servers by region" that's stored in memory on each node and kept synchronized by service discovery. Additionally, if we don't have enough candidate nodes in a given load category, we will grab a few from the next-best load category. The thought being, that for a given region, we'll have a large set of servers to allocate to. This prevents a server failing from thundering-herding another server.
b) A voice server fast-fail (reject) allocation requests, and does so under some circumstances, e.g.: the rate of allocation requests for the server exceeds a threshold, the server is at capacity, or approaching capacity. We do a lot of this fast-failing logic using semaphores around a shared resource (server alloactor): https://github.com/discordapp/semaphore
c) We also run things a bit over-provisioned. We try to have enough excess capacity during peak such that we can handle the failure of an entire datacenter within a region, or an entire region to nearby geographical regions.
>I imagine that estimating capacity is even more difficult since people can join and leave at any time, and the client doesn't send any packets when there is silence. So the load changes based on how talkative people are being (which means your server always crashes during the best parts of whatever you're discussing).
We use a lot of factors to measure load on a server to group it into a load category - in addition to just traffic: we look at concurrent clients connected, concurrent voice servers allocated, packets/sec, bytes/sec.
> ... and the client doesn't send any packets when there is silence.
Yes and no, there's no packets being passed over the WebRTC connection, but the server maintains a WebSocket connection for state changes. There's two, one to the guild service, which handles assignment of the voice service. Want to count the number of clients connected to a voice server? Count the number of connections.
All Discord clients are connected to Guild services and discord publishes events for voice channel updates to all clients in the guild. (Ex. when a person joins a voice channel.)
Also, for larger discord guilds, there are exclusive voice server pools for them to consume.[1] These servers are configured with more resources and are usually pretty close to exclusive to the single guild. Most of the voice servers are for the millions of other guilds though.
> Instead of DTLS/SRTP, we decided to use the faster Salsa20 encryption. In addition, we avoid sending audio data during periods of silence — a frequent occurrence especially with larger groups.
I wonder whether this would help an attacker infer voice data, with a method similar to the one from the paper "Uncovering Spoken Phrases in Encrypted Voice over IP Conversations" [1]
First author of the linked paper here. It's an interesting question.
Actually the voice activation (on/off periods of sending vs silence) was the first thing we looked at in that project. There's definitely some information leakage there, but it was really hard to learn anything meaningful from it. The problem seems to be that long strings of words all get lumped into a single activation. It's really hard to discern anything about what those words are, or even what language they come from.
We got some very weak results on language detection from VAD. You can learn something about the language, but it's not very precise. For example, maybe you could tell that a given conversation is definitely not language A, B, or C, but it might still be language X, Y, or Z.
I've never tried doing pcaps with Discord voice chat yet but it would be interesting "estimating" what was said best on the amount of voice traffic transferred. Might be harder if it still looks like standard Discord TLS "control traffic" blending in though, no?
Deciphering content from latencies in packetized speech is likely much more difficult, but I wouldn't put much stock in it being too difficult.
Which is to say, if you're transferring high-value information assets over VoIP you should probably assume it's decipherable. That doesn't mean you should change what you're doing. You could simple say, "M'eh, I'll worry about it when it becomes a thing." But I wouldn't assume it's confidential to someone willing to invest the time to target and capture the conversations. And I might leave a few choice comments in the source code and documentation so nobody could excuse imprudent reliance on confidentiality with, "But nobody warned me".
This comment isn't really related. I obviously love Discord and have been using pretty much since it became an option, but I wish there was a better UX for people who are in TONS of channels/servers. I find it hard to navigate all my current servers with just the icon -- especially when server owners are changing their avatars frequently.
I think their UX is awful, and their client is very slow in channels with thousands of users. They should open up their protocol so alternative clients can be created, or at least some IRC gateway.
I haven't made many calls but the sound was always crisp.
Readit News
In contrast, Discord has a volume slider that I end up having to adjust for most people. That requires manual tweaking, often while I'm playing a game, and isn't future-proof; just the other day, one of my friends changed his microphone setup and was extremely loud (I had him at 200% when in the new setup he should've been at about 75%).
This is really my only complaint with Discord's VOIP functionality. It is a major step backward from Mumble. (Also, for some reason the Discord community mostly uses voice activated mic instead of push-to-talk, but I don't think that's Discord's fault.)
Which is a very sane default for most people
The only reason you'd want to use push to talk is either you have a lot of people in the channel, you have a loud background or you don't want people hearing stuff not designated for the discord voice (if you're streaming, have irl people in the same room - that kinda stuff)
I couldn't disagree more. Having an open mic setup for gaming is both insane and completely inconsiderate to everyone else in the channel/group.
It's hard not to personally judge people that join a group, whether that's a friend of a friend, someone looking to try out, public LFG lobbies, etc and you can immediately tell they have an open mic configuration. It's maddening.
Breathing, keyboard smashing, mouse clicking, background noise, eating, or exasperated whining every time you die/lose are all annoyances you push on the rest of the channel/group with an open mic configuration. At best it's an annoyance. At worst it's actively disrupting people's game play and team communication.
For the love of all that is decent with humanity, use push to talk.
But that's just me :)
I can't tell you how many times I've ran into users who just cannot get their sensitivity right. So in turn, you end up with a ton of people coughing, sneezing, talking to others, fans, and insert your other favorite background noise. Most users just don't care to set it up right, and it's impossible to get them to adjust it (unless you have some type of Discord Mod / Admin privs on the server at the time to force them to fix it). Otherwise, you have a bunch of users who have to put up with Joe-Schmoe chewing away on his mic.
It's why the Discord servers I'm in 100% completely enforce PTT, zero voice activation allowed.
It might be better with people using Xbox controllers.
The best being when they use speakers so you get some echo. That's usually when they get muted because fuck their lazy-ass.
What were you saying about open mics?
Definitely the community, as Discord provides an option to require PTT on a channel-by-channel basis.
PTT is mandatory running an MMORPG raid with 40 people. Voice activated is perfect for playing a game while talking with 3-8 people at a time.
I think it's more about who you're playing with, if you are good friends with the people that you are on voice with, chances are you're quite alike and considerate to each other.
Deleted Comment
I've said before that I can't really justify nonfree software for something as simple as text chat.
That said, rooms with very large numbers of people trying to communicate with voice/video is one use case where maybe it makes more sense for a commercial product to solve it.
[0] http://riot.im/
[1] https://matrix.org/blog/home/
[2] https://jitsi.org/
Everyone hosting their own Ventrilo/Mumble/Ts3 servers had the huge advantage that not only one single company got all data everyone produces. Not to mention outages.
They say in the blog post
> Routing all your network traffic through Discord servers also ensures that your IP address is never leaked
Yeah, except to your centralized company servers.
> Supporting large group channels (we have seen 1000 people taking turns speaking) requires client-server networking architecture because peer-to-peer networking becomes prohibitively expensive as the number of participants increases.
It's unfortunate, but it's just the truth. The reason we aren't seeing decentralized solutions to the problem that Discord solves is technical. It's not because people don't want it or aren't trying. I just doesn't perform well enough.
> Yeah, except to your centralized company servers.
Which most gamers don't care about.
What they do care about, is what follows that sentence: "preventing anyone from finding out your IP address and launching a DDoS attack against you".
Especially for high profile e-sports figures and streamers, that's a very real problem: they want to interact with their fans using chat/voice calls, without giving bad actors the means to DDoS their residential connections (causing disconnects from game matches etc).
That's also why Discord proxies all embedded media from third parties through their own servers (except for some major sites, that are white-listed).
> For clarity, we will use the term “guild” to represent a collection of users and channels — they are called “servers” in the client. The term “server” will instead be used here to describe our backend infrastructure.
I still don't understand why you ever chose the name "server" to refer to something that is many things, but not a server. Guild is a way better name, and doesn't need disclaimers about your self-chosen terminology being confusing.
So yes, "guild" is a really bad name for the thing pretty much anyone in the target demographic is used to call "server", whether that thing actually was a physical or logical server or not. "Guilds" also used to have a voice "server" to host their voice chat activity, but they did never equal themselves to their voice server, so even if all games out there called groups of players "guilds", it would still be a really bad choice. Someone at Discord apparently learnt on the job that "naming stuff" is one of the two hardest problems in IT ;-)
We don't play MMOs, aren't very organized, have a very flat hierarchy, (admins, regulars, new users) and don't stick to one game very long.
The word guild comes with too much baggage, and that single word choice would likely mean we'd still be on Teamspeak to this day. I don't think I'm exaggerating that point either.
I never considered "server" a poor name, even knowing that it was probably not one dedicated physical server in reality. It's simply the right nomenclature for the target audience.
[0]: A Teamspeak server is definitely a server as I assume you define them.
Should I quit the discords that I don't use? I feel like they stay in sync in the background and if I am in 100 servers and they all post say tons of text I will get massive lags.
Does that make sense? Is there a way to prioritize only the server I have active/I am talking in and freeze the rest while im full-screen/in-game/focused?
WoW alone forces me to have 1 server per class, then 1 server for every guild I'm associated with. Forget about any other game.
You custom implemented many components of webrtc I barely got part of the pats down in my project. So this was really interesting to me.
So not even a VPS like Linode, Discord rent physical servers across the board? Or is there a mix of AWS or some other vendor in there?
https://blog.discordapp.com/the-discord-store-beta-9a35596fd...
Aside from the money we already make from https://discordapp.com/nitro :)
> This is all in beta, so things may change by the time we’re ready to launch. What you see today will likely not be what you see in the future.
https://www.engadget.com/2018/06/12/steam-finally-adds-voice...
[1] https://techcrunch.com/2016/02/01/whatsapp-hits-one-billion-...
I suppose that a perfect health check will prevent this, since the failover will assign failover traffic at exactly the level that the new server can successfully handle. But if it's wrong on the other side (rejects connections when capacity actually exists), then compute resources are wasted "just to be safe".
I imagine that estimating capacity is even more difficult since people can join and leave at any time, and the client doesn't send any packets when there is silence. So the load changes based on how talkative people are being (which means your server always crashes during the best parts of whatever you're discussing).
Anyway, I'm wondering how this all compares to the naive strategy of "pick a random server for this channel, if it crashes, bad luck".
a) A voice server can sit in multiple different load categories. So it's not "best server by score", but rather "best server out of a pool of servers with a given load factor". The load factor is one of ":verylow | :low | :medium | :high | :veryhigh | :extremelyhigh | :full" When looking for a server, we have an index of "best servers by region" that's stored in memory on each node and kept synchronized by service discovery. Additionally, if we don't have enough candidate nodes in a given load category, we will grab a few from the next-best load category. The thought being, that for a given region, we'll have a large set of servers to allocate to. This prevents a server failing from thundering-herding another server.
b) A voice server fast-fail (reject) allocation requests, and does so under some circumstances, e.g.: the rate of allocation requests for the server exceeds a threshold, the server is at capacity, or approaching capacity. We do a lot of this fast-failing logic using semaphores around a shared resource (server alloactor): https://github.com/discordapp/semaphore
c) We also run things a bit over-provisioned. We try to have enough excess capacity during peak such that we can handle the failure of an entire datacenter within a region, or an entire region to nearby geographical regions.
>I imagine that estimating capacity is even more difficult since people can join and leave at any time, and the client doesn't send any packets when there is silence. So the load changes based on how talkative people are being (which means your server always crashes during the best parts of whatever you're discussing).
We use a lot of factors to measure load on a server to group it into a load category - in addition to just traffic: we look at concurrent clients connected, concurrent voice servers allocated, packets/sec, bytes/sec.
Yes and no, there's no packets being passed over the WebRTC connection, but the server maintains a WebSocket connection for state changes. There's two, one to the guild service, which handles assignment of the voice service. Want to count the number of clients connected to a voice server? Count the number of connections.
All Discord clients are connected to Guild services and discord publishes events for voice channel updates to all clients in the guild. (Ex. when a person joins a voice channel.)
Also, for larger discord guilds, there are exclusive voice server pools for them to consume.[1] These servers are configured with more resources and are usually pretty close to exclusive to the single guild. Most of the voice servers are for the millions of other guilds though.
[1] https://discordapp.com/partners
I wonder whether this would help an attacker infer voice data, with a method similar to the one from the paper "Uncovering Spoken Phrases in Encrypted Voice over IP Conversations" [1]
[1]: http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf
Actually the voice activation (on/off periods of sending vs silence) was the first thing we looked at in that project. There's definitely some information leakage there, but it was really hard to learn anything meaningful from it. The problem seems to be that long strings of words all get lumped into a single activation. It's really hard to discern anything about what those words are, or even what language they come from.
We got some very weak results on language detection from VAD. You can learn something about the language, but it's not very precise. For example, maybe you could tell that a given conversation is definitely not language A, B, or C, but it might still be language X, Y, or Z.
Deciphering content from latencies in packetized speech is likely much more difficult, but I wouldn't put much stock in it being too difficult.
Which is to say, if you're transferring high-value information assets over VoIP you should probably assume it's decipherable. That doesn't mean you should change what you're doing. You could simple say, "M'eh, I'll worry about it when it becomes a thing." But I wouldn't assume it's confidential to someone willing to invest the time to target and capture the conversations. And I might leave a few choice comments in the source code and documentation so nobody could excuse imprudent reliance on confidentiality with, "But nobody warned me".
I haven't made many calls but the sound was always crisp.
Both the Rest API (that official clients use internally too), as well as the real-time WebSocket protocol are described here:
https://discordapp.com/developers/docs/reference
https://discordapp.com/developers/docs/topics/gateway
https://github.com/42wim/matterbridge
I also have a fair amount of different IRL/internet friend groups who all have their own channels.