Well, the first problem at home is likely your wireless. Live in an apartment and you can pick up 30 other routers in your wifi search. Chances are you're going to have latency and re-transmit issues to your AP.
Second problem, your router. Most of them suck. If you're lucky and yours doesn't setup QoS/shaping rules. I use fd_codel on mine to attempt to minimize the amount of buffer bloat that occurs. In the race to make your internet 'fast' huge buffers act like buckets for data, which is really bad if you want your data instantly. And if you search buffer bloat you'll see a lot of people talk about it, very few ISPs want to do anything about it though.
Lastly, the one you can't do anything about is the path that your data takes to the remote user. If it is overloaded or has capacity induced latency there isn't much you can do, other than change ISPs maybe.
thewirecutter.com/reviews/best-wi-fi-router/
The documentation is still not stellar, but it has gotten better, and the configuration more consistent. It's quite easy to set up ssh-access with a key, and simply get a copy of configuration files with scp - ready to set up identical configurations on new router installs.
Another problem is cell phones add ~150ms latency (pre VoLTE) and people that route calls through Google Voice adds an additional 150ms+ latency on top. If you ever talk to someone on a cell phone on google voice, it sounds like they're calling from the moon.
150ms is about the human limit before turn-taking and talking over each other becomes an annoyance. That's why cell-to-landline conversations (150ms one way) were tolerable, but cell-to-cell (300ms one way) conversations are abysmal. And that's all in the same area code. Once you add long distance, it gets worse.
Opus is an evolution of SILK which is/was used in Skype.
Maybe this is because traditional communications were built by people working exclusively in that field - and they eventually became true experts, with a deep understanding of the real issues.
Nowadays Internet chat services are cobbled together by happy-go-lucky engineers who, prior to this, maybe did an ads firehose on Twitter, and after this project will perhaps move on to work on Facebook games or whatever. Smart people to be sure, but their understanding of the field is necessarily superficial.
The fast rate of change in this industry explains many of the things that are ailing it currently.
Skype has been around for 13 years. It isn't a young startup full of ex-node.js programmers.
WhatsApp also has some excellent infrastructure built on top of Erlang which has decades of experience and refinement of heavy-duty telecom usage baked into the framework.
If anything the experience of previous development trickles down and younger engineers benefit from that knowledge. But I'm not sure I buy the idea that you can only build great systems if you've only been doing that one category for your whole career.
The rate of jobs changes faster and in front-end development the pace of toolset changes pretty fast. But even in front-end development it's still the same languages. usually just the tools are the trendy part. And if it's switching languages every 5-7 yrs that knowledge of languages is transferable. I've only benefited as a programmer from exposure to many other languages (and projects).
Regardless, the hardcore backend guys you get to build this type of infrastructure isn't the same hipster front-end devs that Twitter hired in the early years to build out a consumer product. Consumer is very different than building out telecom infrastructure in Erlang/C++.
You're remembering incorrectly then. Dialup latency was in the range of hundreds of ms. Early high speed internet access also had higher latency than modern connections.
If you have latency problems it's likely a problem with your hardware.
As for the sample rate, 8 khz is a bit low, but you can make it sound significantly better with a bit of equalization; usually turning down frequencies near 1 khz a little goes a long way. Sometimes too, it doesn't hurt to gently (and I stress, gently) reduce frequencies near ~300 hertz if it sounds too muffled.
I've experienced this with multiple NPR affiliate stations where it's particularly noticeable for their generally high audio quality.
My suspicion is that audio is recorded with different codecs or at different bitrates, though I've never been able to establish this.
I've also not noted the problem for a few years, so it may have been addressed.
Lots of people who had ISDN kit plugged their old POTS phones into their TAs anyway.
Any plans to make this available to developers as a service via AWS?
What is interleaving in this context?
The latency is almost palpable.
But the most annoying problem with any internet voice chat is not so much the quality but the latency. Landline phones have noticeably lower voice quality but one can still enjoy a conversation perfectly well. High latency, on the other hand, absolutely ruins the experience.
I always see these services talking about "crystal clear quality", but never latency, which is a shame. Maybe there is simply nothing they can do about it. I've noticed latency get worse and worse on the Internet since I started using it in the 90s and nobody seems to talk about it.
There are so many more sources of latency on every layer on the modern internet and it's a damn shame. I remember when interleaving got enabled on my ADSL and latency to everything doubled overnight. Then there are NATs, and all kinds of filtering shit that ISPs insist on. Sigh...