WebRTC 1.0 telephony app using “hifi” Opus codec with up to 500kbs bitrate | Hacker News Reader

WebRTC 1.0 telephony app using “hifi” Opus codec with up to 500kbs bitrate

timur.mobi

149 pointspfalafel76 comments

Mumble uses Opus by default. You can definitely tell the audio sounds much better than competitors although mumble is more fussy about mic and background noise as it does less processing than Skype for example.

Opus was originally intended to be a general purpose codec that maintained fidelity at even low bitrates which makes it suitable for telephony as it's also low latency. On the other hand it also sounds good at higher bit rates and I use it as my codec for my music when I convert them from flac for mobile devices.

Discord and TeamSpeak also use Opus, and Skype transitioned to Opus near the end. Opus became the de facto codec for phone applications over the past decade.

Opus is the de facto codec for phone applications, other than you know, the publicly switched telephone network which is still mostly stuck on G.711 and only finally rolling out "HD Voice" G.722.

If the device manufacturers could get their shit together and come up with some cross-manufacturer federated standard, we could easily dump the public telephony network once and for all. I’ve never been anywhere (rural or urban) where public telephone was better quality than some kind of VoIP. Even out in the boonies, data is usually more reliable than voice (at least with google fi).

The craziest thing is its not even really the device manufacturers, its usually the networks themselves. I've had SIP phones capable of good quality codecs for a long time but getting a carrier to actually support them and have a handshake actually complete with those is nearly impossible. My handshakes out always signal I'm Opus capable (along with a lot of other codecs) but almost every call in and out of my phone system is G.711. Calls internally sound wonderful though :)

I dont know why but I never had much good experience with VoIP on the street. VoLTE with EVS [1] has been superb.

[1] I think they are called HD Voice+ in some market.

If you have a G.722 capable voip desk phone or softphone on your own asterisk system, where G.722 calls work between any two extensions on your system, and you are making calls into the regular PSTN... It is almost certainly ending up as G.711 anyways if you're calling another carrier.

Particularly if you are using a SIP trunking service to reach any international destinations outside of the US50 states and Canada, it's going to be regular G.711 alaw or ulaw.

G722 was also available on some ISDN phones in the 80ies.

Highly recommend Nvidia's Broadcast to filter out mic noise if you can run it.

Opus and Mumble are free software. Nvidia's processing stuff is not.

I mean it is free if you have the card anyway, but sure.

I didn't mean free as in "costs $0". The software comes with a restrictive, proprietary license, and no source code is provided.

I guess everyone has the choice to use the best one or the free one but rarely at the same time.

Except in the case of Opus, by the sounds of these comments here.

I'd like to run hardware-accelerated noise cancelling of RNNNoise-quality. For me, Mumble has a serious background CPU usage problem as soon as I turn that noise cancelling on, even if I'm client-side muted.

I can only offer an i915 (Broadwell) target for said offloading, though.

Mumble has Xiph's RNNoise — which is Free and Open Source — built-in, thank you very much.

RNNoise was trained from proprietary data, so it isn't exactly an open AI model that could comply with the Debian Deep Learning Team's Machine Learning Policy.

https://news.ycombinator.com/item?id=25978309 https://salsa.debian.org/deeplearning-team/ml-policy

So...?

So calling it "Open Source" seems incorrect.

Jamulus - an app for playing live music together online with minimal latency - also uses Opus.

It works well for game music with standard audio tags. The files can be much smaller than mp3 with higher quality.

Opus is also often just used generally. Youtube uses opus for the audio in videos

> Opus was originally intended to be a general purpose codec

Well, Opus was originally intended to be two codecs, which got merged into the beauty that is Opus now.

Yep. Opus evolved from merging SILK and CELT. It’s like magic.

Unfortunately, adoption in the digital audiophile hardware world seems very low. E.g. none of the flagship digital audio players from FiiO, Shanling, Cowon, Astell&Kern has built-in support for Opus, even though the codec is completely royalty-free.

Signal also uses opus by default, and I have found that audio quality on Signal voice calls is uniformly excellent, unless one person's end is experiencing very high packet loss (which would significantly hurt any VoIP application)

Timur is a really fun guy. He also wrote and maintained the (since quite famous) kernel patches and userspace utils for Nexus7 devices to allow USB host mode and charging simultaneously. The hack itself was modest enough but it since enabled a whole new world for DIY in-car entertainment enthusiasts, providing the modding community with a simple and affordable way to fully integrate a working tablet into their cars with USB DACs, DAB dongles, back-up cameras, etc - which was pretty slick stuff back in 2012-2013.

I am the developer of this web-app and you can use the link (say, for the next hour or so) to give me a direct voice call. I am interested in finding out about audio quality in the real world. Thanks

Is there a source code or more details? Does it connect to SIP or PSTN gatewaY?

No 3rd party services involved at all. All server components are running on a single server of mine. Sorry, no source code released yet.

I keep getting a busy signal, you must be popular!

Nice speaking with you! (your new friend from New Jersey)

If you can still edit the title, I suggest prepending "Show HN".

The codec is interesting but I’m actually curious how you’re arranging the calls without signaling servers, per your about page. Can you share a bit about that?

The about page says "no 3rd party servers," not "no signaling servers." The STUN and TURN servers configured in the source code are the same IP that timur.mobi resolves to, so the web server is just also running the signaling servers.

Hey there! What would be required to host my own version of this style of call access? adapter-latest.js and caller.js from the HTML source? Is there any more information to do something similar?

I had no idea what I was getting into when I clicked "Call Now" but wound up having a great conversation with a new friend-- Timur! The audio quality was excellent. This project has great potential. Best of luck to the author!

Opus at over 40 or 60Kbps for voice sounds like overkill, nevermind 500kbps. What's the rationale for using such high bitrates?

I configured the max possible bitrate in the spec. I wanted to find out what is being used in the end. And how it sounds. Most people are calling without a microphone. Please use a headset.

You should look up some subjective quality test results for Opus (voice). The MOS curve flattens at about 40kbps, IIRC.

OpusFAQ: "Opus scales from about 6 to 512 kb/s" - https://wiki.xiph.org/OpusFAQ#In_what_ways_is_Opus_optimized...?

Edit: quote from section 1.14 (direct link does not work bc of the question mark in their section ID)

Probably marketing and the HiFi industry has demonstrated that such people are a nice niche income stream. Some say a fool and their money, I say each to their own and their choice.

But I'm sure there are always edge-case valid uses for such audio quality. Maybe talk to bats and dolphins in the future is now one step closer than before is another way of looking at this.

Opus doesn't support any sample rates higher than 48khz, so no bat encoding. Some other audio codecs do, but it doesn't really make a lot of sense and I doubt they've been properly tuned for it.

Oh indeed you are spot on - https://wiki.xiph.org/OpusFAQ#Does_Opus_support_higher_sampl...

But that 500kbs sound just feels warmer to me (on my laptop).

I think the 500 limit is a max bitrate setting, independent of any specific codec. If you deliver audio+video you will need to consider exactly how much of the bandwidth you use for audio. But when doing audio only, simply using the highest possible bitrate seems to be a reasonable choice. In most cases the network will set limited.

Samplerate is an independent dimension of bitrate - although not really because lower bitrates can store fewer samples.

It's equivalent to the resolution of an image.

Sample rate is limit on the frequencies in the original signal that you can represent in your digitization without aliasing.

Sample rate != bit rate. 48khz samples at 16bits each is 768kbps mono. 1.5Mbps stereo. But that's before compression.

The point was that Opus can't store bat sounds because they're ultrasonic and it isn't. Dolphins may be possible though I think whales might be filtered out due to being subsonic.

Opus at sample rate of 48khz, still only encodes frequencies up to 20khz of listening range (think of opus as having 40khz sampling rate).

This is same as audio CDs, which although are in 44khz sampling rate, have a red book recommendation to always filter out anything over 20khz.

Thing is, most people can't hear well over 16khz. Some can hear 18khz. 20khz is peak possibility. To encode 20khz wave we need 40khz sampling rate. Everything else is marketing.

"640k [bitrate] ought to be enough for everyone"...

For mono audio, even 32k Opus is nearly CD quality, and 64k is indistinguishable from uncompressed audio in non-audiophile contexts.

500k is simply ludicrous.

Would not be ridiculous for serious online musical collaboration where you might want to send many channels at once. Perhaps there is some benefit to multiplexing inside Opus, instead of having separate channels? (Probably a similar argument as the one in favor of monorepos).

In this context, latency is far more important than actual audio quality. Human ears are notoriously bad at judging the "quality" of sound, but extremely good at detecting latency between visuals and audio. This is why lip sync is such a problem in home cinema systems.

Well, considering that I can hear a difference between lossless and ~80k Opus (stereo) with a decent headphone amp and 16 EUR Sony in-ear's, I can't share your sentiment. Granted, this is fairly pathological synth sound (the intro/first 30s of Night Club's "Magnetic"), but I would hardly call that listening equipment audiophile.

80k stereo is (approximately) 40k mono. We seem to have the same sentiment.

No, I'm saying that this is very much distinguishable without exotic hardware, on music not deliberately created to expose compression artifacts. And at a bit rate higher than what you claimed to be transparent on non-audiophile setups. And calling <20$ headphones (that includes an in-line microphone) on a Thinkpad's built-in headphone amplifier "audiophile" seems inappropriate. I do hear a difference (on FLAC) between those cheap headphones and some ultra-low-distortion 2-way half-open headphones, with the latter being notably more clear.

You said 64k stereo aren't distinguishable from FLAC with normal, consumer-grade listening equipment. I said I hear a difference between 80k stereo and FLAC using a laptop built-in headphone amp and the cheapest headphones that didn't look like a consumable.

They said 64k mono is indistinguishable, not 64k stereo.

You're talking about stereo and I'm talking about mono, as I tried to explain in the previous comment.

the idea that 64k opus is indistinguishable from uncompressed is so ridiculous... the caveat being "if you have shitty equipment" is not any sort of argument at all. if you have shitty equipment, nothing ever matters. is that an argument for anything at all?

people love dunking on hifi-- it's such a meme at this point.

edit: ah yes, i forgot about the "i disagree" button to the left of my name... feel free to use it, i guess. clearly, as a hifi stan, i doth protest too much... (and am just an idiot)

every other commenter agrees that this is a bad take, but i guess because i highlighted that this sort of comment is typical to this discourse i am somehow breaking social mores

At this sort of bitrate I am wondering if AAC-LD ( Low Delay ) could be used on Apple platform.

And speaking of that I am wondering if patent has expired on that just like AAC-LC.

Why? Opus is superior to AAC-LD, not patent encumbered and, as far as I know, supported by Safari for WebRTC.

I am just increasingly fond of "patent free" codec. Like AAC-LC and Good old MP3.

I made a lot of phone calls tonight. Two quick observations: 1) Many people think I'm a bot. And they want to test me with smart questions in order to find out if I'm a bot. How do you prove that you are not a bot? 2) It seems that aprox 90% of the calls are getting relayed. I expected more calls to come through as P2P. The audio quality is still excellent in most cases. If both sides use a headset, it is almost better than sitting next to each other. This is much better than normal telephony.

Ooh... reminds me of a throwaway experiment I did a few years back - WebRTC for radio outside broadcasts. It never went far as we ended up going down the SIP path instead. Nice to see the idea going further though there are commerical products now that work on this basis (IPDTL is one that rings a bell).

Both approaches were a great improvment over the need for an ISDN line but you could run into problems running higher bitrates on "spotty" networks. Thankfully you didn't need more than 128/192kbps for broadcast quality most of the time and could get away with even less for voice.

Call Server: https://bitbucket.org/marcsteelesoftware/g-rtc-call-server/s... Frontend: https://bitbucket.org/marcsteelesoftware/g-rtc/src/master/

Tried to call a few times and got the busy signal. Just a thought but I would maybe not log the number in the console as it might be leaking your actual phone number to the wider world. Hope it's a burner number.

Your phone number is not getting leaked by an WebRTC app. Definitely not. Your IP address might, in case a true P2P connection is established.

Not even that - WebRTC obfuscates your IP via intermediary servers.

TURN/STUN servers are not always used, and more often than not only as a fallback if a direct link is not established.

Small addition to avoid confusion: the purpose of STUN is kind of the opposite of TURN in this context. TURN will tunnel the traffic through the server and the clients don't need to know each others real IP addresses. STUN on the other hand is used in order for the clients to learn their real IPs despite NAT and be able to establish a direct connection.

Adding a "I am not a robot" button to initiate the call would be really cool way to avoid bots in the future if this ever catches on.

It's WebRTC... millions of bots would not affect a thing.

> It works best in Chrome, Chromium and Firefox (all v80+).

I'm assuming Edge also?

Is there any way this could be integrated with Twilio Voice?

Reply on news.ycombinator.com