I have never heard anyone complain about Mumble's UX. Especially not that it has gotten worse. Or it's resource usage, which is practically unnoticeable on any average system sold past 2005. It's the best-in-class and has only gotten better.
That's just not true anymore these days. I've used WebRTC between Firefox, Safari, and Chrome without any issues.
> only if you use the same kind of software and codecs, for example Chromium, that requires dozens of gigabytes of disk space and much RAM, CPU time to build it.
There seem to be non-browser implementations [1] [2], although I can't vouch for their quality.
[2] https://github.com/awslabs/amazon-kinesis-video-streams-webr...
> only if you use the same kind of software and codecs
With WebRTC I can connect clients with varying support of H264, VP8, VP9, AV1, Opus, ulaw and alaw. WebRTC has plenty of flaws, but 'lack of negotiation' is one of them.
Edit: Woah, I somehow completely missed that Pion does WebRTC media too (I've only seen it in a data channel project I've toyed around with in the past). Definitely add that to my list above, and I can somewhat vouch for it, it's cool!
* https://github.com/elixir-webrtc (Elixir)
* https://github.com/pion/webrtc (Golang)
* https://github.com/webrtc-rs/webrtc (Rust)
* https://github.com/algesten/str0m (Rust)
* https://github.com/sepfy/libpeer (C/Embedded)
* https://github.com/awslabs/amazon-kinesis-video-streams-webr... (C/Embedded)
* https://github.com/paullouisageneau/libdatachannel (C++)
* https://webrtc.googlesource.com/src/ (C++)
* https://github.com/shinyoshiaki/werift-webrtc (Typescript)
* https://github.com/sipsorcery-org/sipsorcery (C#)
* https://github.com/aiortc/aiortc (Python)
* GStreamer’s webrtcbin (C)
I'm not able to access the site over TLS, so this is currently impossible. Anyone else have better luck?
(from the installation instructions)
$ [fetch|wget] http://www.vors.stargrave.org/download/. vors-2.3.0.tar.zst
$ [fetch|wget] http://www.vors.stargrave.org/download/vors-2.3.0.tar.zst.sig
[verify signature]
$ tar xf vors-2.3.0.tar.zst
Sorry, I don't see how that follows. If you had access to the webserver you would never even attempt a MITM attack in the first place.
I would also push back that "most websites" use a 3rd party TLS terminating CDN/proxy layer in front of the actual webserver.
Stand next to someone in game and they came through loud and clear. Move away from them sideway and it's now quieter and only through one headphone... I found it extremely novel and immersive when I used to play FPS games; everyone on mumble but absolutely not like being in a chatroom.
See:
I've been idly hacking on something quite similar but using QUIC instead. One of the downsides with QUIC of course is that it assumes TLS by default which makes it inefficient for use on encrypted transports (like wireguard, zerotier, tailscale, or yggdrassil.) I'll definitely give this a go as I'm a big fan of NNCP, another project by the author.
I'm old enough to have spoken to people on analogue land lines: the sound was crisp, you could hear small background noises, you could hear someone breathe.
Nowadays we usually speak to people on digital lines that are highly compressed (to the extend that is messes with the sound quality), low freq range (no bass, very high sounds) and cut up (without enough sound or when then other party makes more sound the stream is completely interrupted).
And it does not have to be like this! All of this is in favour of the network operator (or centralized chat servers e.g. whatsapp) trying to save some data/money. While many of us have paid for unlimited data!
On top of that much of the conversations are not properly e2e encrypted!
I've used Mumble to speak to people I love over long distance and the quality is just so much better: it's like the analog experience of my childhood. Hearing ever breath, background noise and all in high quality makes all the difference some times.
You're old enough to have forgotten what land lines sounded like.
They intentionally dropped frequencies from the audio signal so that they wouldn't have to carry the data contained at those frequencies. This is why nobody ever sounded like themselves over the phone.
This is the reason broadband internet (ADSL) is called broadband. Because dial up internet used the POTS frequency band below 4 khz, and broadband used the (broad) frequencies above.
It's also the reason you'd have to get a technician out to your house in order to get ADSL. They would install a frequency cutoff filter on the phone line into your house, and hookup the landline to the below 4 khz side and the ADSL modem to the above 4 khz side, so the POTS signal would not interfere with the ADSL signal.
I feel like I've actually noticed the opposite. My parents still have a landline, although it's basically VoIP (through their cable company) but it's connected to the analog lines in their house. I've noticed they generally sound clearer on their cell phones than they do on the landline.
I remember switching from early GSM phone to a landline because I like to hear my love breathe
Anything newer than (heavily depending on the country, probably) the 70s or 80s or so would have been very likely PCM u-law or a-law at 64 kbps (i.e. 4 kHz audio bandwidth at 8 bit), which is literally a mandatory codec in WebRTC.
It would have to be a really old, purely analog baseband line without filters (maybe a local call between offices), frequency modulation etc. to preserve more than the typical 4 kHz of audio bandwidth you'd get on these. Inter-trunk connections were often frequency multiplexed to fit more channels onto a physical wire, which also limited them to 4 kHz.
Today, 64 kbps gets you much farther using a modern codec like Opus. WhatsApp sounds better than any landline or native mobile phone connection I've ever used in my life.
> (or centralized chat servers e.g. whatsapp) trying to save some data/money
WhatsApp uses P2P for (non-group) calls if at all possible.
There's also a "save data for calls" option in the settings which is off by default.
Modern codecs are so good, adding even more data would literally not make any discernible difference. A sizable fraction of all data transmitted/received by modern VoIP is IP and UDP framing overhead.
I've never used WhatsApp to call. I have used decent SIP connections with G.722 Wideband or OPUS. They sound better than the old landlines. Discord sounds better too. Signal, much worse.
I think often the problem is that cell phones really have crappy speaker and microphone placement for calls, as basically nobody actually makes calls on them anymore.
https://github.com/Johni0702/mumble-web
I've never used it but it should make having a p2p conversation through Mumble as easy as pointing your browser to some URL. UX matters (Mumble clients, including mobile apps, are not very user friendly last time i checked: they require some level of skill to use them)
Unmaintained for the last 4 years, sadly.
It would also be great to have this running on ESP32 or similar, so you could make dedicated IP desk intercoms - I envisage a star-trek style intercom, with each button being a channel that you can join by pushing it in (can join multiple simultaneously).
ESP32 has its own port of the Codec2 library, which allows intelligible communications using very low bandwidth (a few kb/s). It could make the ideal solution for creating small cheap intercoms scattered around a small area using WiFi, or employing very low bandwidth radio connection such as LoRa for wider coverage. I still didn't see any real application, beside a few simple proof of concept videos on YouTube, though.
More info:
You can game on Linux just fine.
If not for Valve/SteamDeck this would be even more dire, and many of those experiences are still emulation-based i.e. Proton.
If you want to be able to play any given computer game being sold this year, that's only reasonably certain on Windows. Gaming is the only reason I still have a Win10 install.
For security reasons, browsers don't allow Web sites access to raw TCP or UDP sockets.
Only I spent minutes looking for the git repo link... There is none?
Eh why would someone need a fancy real-time refreshing TUI for a voice application? Just write logs to stderr and status updates to stdout like regular people.
Honestly, go a step further. Take microphone audio in on stdin and produce speaker audio out on stdout. Then you can skip ALSA/OSS/jack/pipewire/pulseaudio support and just leave that to the user to compose.
