VoRS: Vo(IP) Simple Alternative to Mumble(vors.stargrave.org) |
VoRS: Vo(IP) Simple Alternative to Mumble(vors.stargrave.org) |
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.
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).
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.
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.
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.
If I ever can be helpful with your projects reach out!
The problem is that when calling across networks, the connection might still go over a legacy circuit-switched exchange, and that compresses everything down to narrowband again.
I hope that whoever regulates the PSTN in the US will force a switch to all-IP interconnects at some point, since now we get the worst of both worlds (often somewhat lower reliability due to badly managed VoIP services, combined with potato quality because of a legacy interconnect somewhere between VoIP networks).
All IP could also provide much more efficient routing: Right now, as I understand it, if you're calling somebody with a 212 area code and both you and the callee are physically in San Francisco, your connection might still be routed through some circuit-switched exchange in Manhattan, which isn't great for latency or high availability.
Lots of documentation and demonstrations. And honestly, probably a bit better SEO or maybe searching on my part. For some reason GStreamer's webrtcbin totally flew under my radar.
Also not trying to be snarky/negative about WebRTC. I think it's fantastic at what it does. But as a tinkerer, I want something with more tinkering surface area. Not to detract from the great work on WebRTC and how accessible it's made low-latency streaming.
I've learned a lot about it over the years by following https://webrtchacks.com/, which does just that, i.e. taking apart various open and closed VoIP implementations (WebRTC or otherwise) and seeing how they work.
I'm more concerned with the data they receive being leaked or sold.
And by most websites I guess I meant large ones that people frequent every day, because these days it's almost impossible to have any sort of useful DDoS protection without using such a service.
But that's not what we're talking about here. We were talking about a MITM attack on key/tarfile distribution in the context of verifying file integrity.
The only things that do give problems (besides new releases which are promply fixes) are some multiplayer games with anti-cheat that intentionally breaks under Linux. But if you support those kinds of games then you reap what you sow.
Proton is also not really magic - it's mostly just Wine + DXVK and while Valve has improved both they didn't start either of them and weren't involved before they became viable. SteamDick is entirely irrelevant here - if anything it has caused developers to not release native Linux builds because of the way Valve does certification (or unfounded fears on the devs side).
> If you want to be able to play any given computer game
Moving goalpoasts much? This is like saying you need to be an american in order to use computers because there are some computer models that were never exported. There are more games than you will ever be able to play which work under Linux, for any genre. For older games it is often even easier to get them to work under Wine/Proton compared to native Windows.
1. Overwatch -> works great in Proton, albeit about 20% slower than Windows
2. Factorio -> works great natively on Linux, maybe even better
3. Warframe -> works okay in Proton but crashes sometimes
4. Call of Duty (recent) -> kernel anti-cheat both fails to stop cheaters and refuses to work on Linux
I tried living the Proton lifestyle for about 2 years, from around 2019 to around late 2021. Then I just dug my old computer out, reinstalled Windows 10, and went back to using Windows for games.
[1] https://AreWeAntiCheatYet.com
The Steam top 1000 games:
Rating System: ProtonDB Medals
29% Platinum
47% Gold
11% Silver
3% Bronze
4% Borked
In aggregate:
76% P+G (Games you can just play)
86% P+G+S (Games you can play with minor tweaks)
Anticheat:
154 Supported (45%)
39 Running (12%)
3 Planned (1%)
118 Broken (35%)
25 Denied (7%)
It's particularly ridiculous that you're complaining about digital lines having a low frequency range.
Whatever you remember, it isn't reality.
I think for a lot of us later Gen-X and older Millennials, as we age our ears don't work as well as they used to. Especially those of us like me that didn't heed good ear protection. I can't speak for everyone, but I suspect if today me tried to talk to someone on a landline back in the early 90s it'd still suck as bad as it feels like it does with cellphones today. We get more range with our phones now but our ears have a harder time processing it.
Just a thought.
On top of that, I think many remember "landline quality" in terms of a relative comparison with potato-quality early mobile phone codecs, analog mobile phones, heavily compressed discounted long-distance calling circuits etc. of the time.
Yes, landlines were better than any of that, but it doesn't mean that they were actually good by today's standards.
Voice over mobile data will benefit from a different type of data compression relative to how data packets are handled in a cellular radio vs a wired internet.
The landline service could be as clear or clearer than mobile data, it just isn’t configured to do so in your case. I have seen VoIP setups using a high quality codec and a handset that can use those frequencies.
Phone companies use different setups that compress to their advantage for many more callers.
The main difference is that the bandwidth available was just much lower, so mobile codecs are compressed more. (Satellite phones take this to the extreme – 2.4 kbps is a typical data rate after compression there!)
But so were e.g. international trunk lines; they squeezed a lot more than one voice channel into 64 kbps using compression, silence suppression etc.
> The landline service could be as clear or clearer than mobile data, it just isn’t configured to do so in your case.
An analog landline has relatively little chance of ever gaining wideband support, since that would require swapping out line cards at the provider, and the trend seems to be to get rid of these entirely (in favor of a VoIP adapter in the CPE).
I think I've once used "HD voice" on a "landline" when calling a mobile phone, but that only worked because my home router was actually doing SIP in the background.
The big mobile carriers actually have VoIP interconnects preserving wideband audio, while connecting to an (especially smaller) landline carrier might still involve a circuit switched path (going to the physical location of the area code dialed, too!) that inevitably forces everything through a 4 kHz, 8 bit bottleneck.
Which? Whatsapp call sound shit. Mobile phone calls sound shit.
I did Mumble to get some acceptable quality.
Not for me; it's way better than any landline I've ever used.
Not sure what we're doing differently – are you sure it's not your or the other party's speaker or microphone?
> Mobile phone calls sound shit.
Not for me either, at least not when EVS ("HD voice") is used, which is more often than not these days when calling friends/family.
2G connections used to sound quite bad, but since 4G, the limiting factor for me has been the other side being on a landline (mostly for business calls), which usually doesn't support wideband audio.
The default codec configuration for Mumble is opus.
