4 ms·

Mumble has a bunch of issues, the main one being their confusing UI, especially on mobile clients. I'm regularly in mumble conferences and for example accidenta

Mumble has a bunch of issues, the main one being their confusing UI, especially on mobile clients. I'm regularly in mumble conferences and for example accidentally switching the room instead of pushing the push-to-talk button happens quite often. There's also a bunch of more technical problems. For example as mumble uses a udp protocol it handles dropped frames badly, like on a spotty wireless connection. Results in missing audio. Not just that sound doesn't arrive (in both directions) but it also doesn't tell you something's wrong. Mumble has problems with changing audio setups which require a restart of the client. Also no video, no simply calling people - you need to go to a server and they need to go there, too. Basically stopped innovating some time ago and everone else moved further.

deleted 5y ago
[deleted]
mrtesthah 5y ago
>For example as mumble uses a udp protocol it handles dropped frames badly, like on a spotty wireless connection. WebRTC also uses UDP—as well as virtually every other real-time conferencing platform since the internet existed. TCP is too constraining to use for voice because every single packet retransmission only increases delay further. Dropping packets when they don’t arrive on time is necessary in order to minimize delay, which is one of the principal goals of Mumble. The real solution to dropped packets is not TCP—it’s a quality jitter buffer, and if you don’t like mumble’s performance in that respect then you need to look at the JB. A good JB will buffer and reorder packets within some statistical measure of network jitter, but the behavior is very explicitly not to retransmit. https://www.cs.columbia.edu/~hgs/rtp/faq.html#reliable https://www.cs.columbia.edu/~hgs/rtp/faq.html#reliable Google cheated with their implementation of WebRTC by purchasing Global IP Solutions, which gave them the most advanced jitter buffer in the world at the time: NetEQ. http://www.gipscorp.alcatrazconsulting.com/files/english/datasheets/NetEQ.pdf http://www.gipscorp.alcatrazconsulting.com/files/english/dat... https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_coding/neteq/g3doc/index.md https://chromium.googlesource.com/external/webrtc/+/master/m...

deleted 5y ago

[deleted]

mrtesthah 5y ago

>For example as mumble uses a udp protocol it handles dropped frames badly, like on a spotty wireless connection. WebRTC also uses UDP—as well as virtually every other real-time conferencing platform since the internet existed. TCP is too constraining to use for voice because every single packet retransmission only increases delay further. Dropping packets when they don’t arrive on time is necessary in order to minimize delay, which is one of the principal goals of Mumble. The real solution to dropped packets is not TCP—it’s a quality jitter buffer, and if you don’t like mumble’s performance in that respect then you need to look at the JB. A good JB will buffer and reorder packets within some statistical measure of network jitter, but the behavior is very explicitly not to retransmit. https://www.cs.columbia.edu/~hgs/rtp/faq.html#reliable https://www.cs.columbia.edu/~hgs/rtp/faq.html#reliable Google cheated with their implementation of WebRTC by purchasing Global IP Solutions, which gave them the most advanced jitter buffer in the world at the time: NetEQ. http://www.gipscorp.alcatrazconsulting.com/files/english/datasheets/NetEQ.pdf http://www.gipscorp.alcatrazconsulting.com/files/english/dat... https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_coding/neteq/g3doc/index.md https://chromium.googlesource.com/external/webrtc/+/master/m...