Hacker News Reader

Comment by codethief | Hacker News Reader

> Lots of people are stuck on low-bandwidth links so a codebase optimized for slower connections would absolutely fly (and consistently so, for everyone, under lots of conditions), and everyone always wants to use less bandwidth anyway.

You would think so but why have solutions like Mumble[0], which allows for extremely low-latency and high-quality voice calls and has existed at least since the mid 2000s, not become more popular during the pandemic? Or why didn't people at Zoom and MS Teams at least learn from Mumble?

[0]: https://www.mumble.info/

View on HN

> You would think so but why have solutions like Mumble[0], which allows for extremely low-latency and high-quality voice calls and has existed at least since the mid 2000s, not become more popular during the pandemic?

Because there is no official Mumble server.

People know how to download an application, click "install", and register an account. But ask them to open a port on their router's firewall/NAT, or set up DNS, and you instantly lose 99.9% of your user base.

It could have been different, but lay people never had the chance to install their own server. They couldn't do it with Dial Up, they didn't have the upload bandwidth with ADSL, they didn't have fixed IP addresses, there's the NAT hurdle, outgoing SMTP is blocked everywhere… that ship has sailed. Even I host my websites on a remote virtual machine I rent.

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.

>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

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/dat...

https://chromium.googlesource.com/external/webrtc/+/master/m...

Long enough mumble sessions will desync and the developers don't want to do anything about it. Mobile clients all suck. Mumble is great, but it has flaws too :)

How long are we talking? I remember being in Mumble sessions for hours quite often back in ~2007, 2008 and I never noticed anything like that.

Usually happens when there's bad connectivity.

Reply on news.ycombinator.com