Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google open-sources the Lyra audio codec

opensource.googleblog.com

Post reply on HN
Print view View original

101–110 of 145 posts

Re: Google open-sources the Lyra audio codec

#101

Post by posguy »

danaliv wrote: post #51
ncmncm wrote: post #47

Earlier quoted context omitted.

[update: proprietary .so] They should re-implement the needed bits of libsparse_inference before releasing this thing. Otherwise it's just a distraction. Probably they should get it building with something other than Bazel, too.

It's not a kernel module, it's a compute kernel. Nothing to do with operating systems. They provide versions for android-arm64 and linux-x86_64. The fine README says it builds and runs on Ubuntu 20.04.

Ah, so Lyra today will not work on RISC-V, i386, Power, MIPS, lower end or older ARM chips like the Allwinner H3 (very popular in Single Board Computers) and any other new architecture that comes out?

Re: Google open-sources the Lyra audio codec

#102

Post by posguy »

p1mrx wrote: post #93

This seems kind of unnecessary, compared to Opus at ~10 kbps. If you're sending IPv6+UDP in 40 ms chunks, that's 9.6 kbps just from the packet headers (25 Hz * 40+8 bytes). When the voice payload is smaller than the packet headers, you're well into diminishing returns territory.

Opus at 8Kbps sounds better, and commodity, inexpensive hardware like the Grandstream HT802 Analog Telephone Adapter supports this codec today (along with any cheap Android phone).

Lyra as it stands today will not support anything outside of x86-64 and ARM64 without rewriting the proprietary kernel it relies on.

Re: Google open-sources the Lyra audio codec

#103

Post by colanderman »

YarickR2 wrote: post #94
miohtama wrote: post #89

If I remember correctly the original landline audio was 64kpbs, 8000 Hz. So Lyra is 1/20 of this. And probably still sounds better.

Original landline audio was/is analog

Not an authoritative source, but (as a point of interest) analog landlines seem to be specified as 24 dB SNR and 300-3000 Hz passband [1], giving ~21.5 kbps information rate [2].

[1] https://www.tschmidt.com/writings/POTS_Modem_Impairments.htm

[2] https://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theore...

Re: Google open-sources the Lyra audio codec

#104

Post by bilal4hmed »

I have been using Duo more for audio calls lately and the call quality has been excellent. Compared to WhatsApp its much much better which often times can mimic the sound quality of a regular phone call. Ive tested in the US and with my family in India, where the connection isnt the greatest

Re: Google open-sources the Lyra audio codec

#105

Post by taneq »

beagle3 wrote: post #95
pjc50 wrote: post #14

One thing I'm slightly worried about "machine learning" in compression rather than conventional everything-is-sines mathematical approaches is the possibility of odd nonlinear errors. Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers? I don't mind compressing a phoneme to as much as I would mind it compressing it to a clearly audible different phoneme.

Are you aware that the same exact uncompressed recording sounds different depending on context? This is known as the McGurk effect. Very worth your two minutes if you're not yet familiar with the effect: https://www.youtube.com/watch?v=2k8fHR9jKVM

While fascinating, that’s not the same as a codec failing silently by literally changing one word into another, equally clear word instead of getting fuzzy or unintelligible.

Re: Google open-sources the Lyra audio codec

#106

Post by zamadatix »

0b01 wrote: post #17
Bedon292 wrote: post #12

Earlier quoted context omitted.

I don't think it is discussing encoding time in the article, it says "features are extracted in chunks of 40ms". My reading is that its breaking down the speech into 40ms chunks, compressing it, and sending that.

But since the buffer size has to be 40ms then so the minimum latency is 40ms

Sure latency ends up being 40 ms but that's a function of needing to wait to send the encoded data + network headers at 6 Kbps not a function of the encoder being slow holding everything up.

Re: Google open-sources the Lyra audio codec

#107

Post by ekianjo »

smnrchrds wrote: post #21
pjc50 wrote: post #14

One thing I'm slightly worried about "machine learning" in compression rather than conventional everything-is-sines mathematical approaches is the possibility of odd nonlinear errors. Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers? I don't mind compressing a phoneme to as much as I would mind it compressing it to a clearly audible different phoneme.

This one too: https://petapixel.com/2020/08/17/gigapixel-ai-accidentally-a...

Thats not a compression algorithm

Re: Google open-sources the Lyra audio codec

#108

Post by zamadatix »

robert_foss wrote: post #6

Encoding takes >40ms? Opus takes 5-26.5ms. Apparently 150ms[1] is the generally accepted upper bound for call latency. I think the article could do with some bandwidth/quality/latency/power comparisons to other codecs. [1] https://en.wikipedia.org/wiki/Latency_(audio)

There is no such thing as 5ms VOIP audio latency at 6 Kbps, the IPv4+UDP headers would amount to 44.8 Kbps at minimum, so it's irrelevant if one encoder is tuned to be able to encode 5 ms chunks instead of 40 ms chunks. 40 ms intervals requires a minimum of 5.6 Kbps + the codec rate.

I.e. at 10 Kbps it's impossible to have a lower VOIP latency than 32 ms. Likely the 40 ms number they tuned for in the real world.

Re: Google open-sources the Lyra audio codec

#109

Post by YarickR2 »

nyanpasu64 wrote: post #54
bobthechef wrote: post #39

Earlier quoted context omitted.

> you can't exactly coach a layperson on how to talk "the right way" to not trigger this vowel collapse I've never noticed. At any rate, we should not coach people to adapt to technology in this way. It is Procrustean and anti-human and unnecessarily places a burden on people that belongs to the software and the developer.

For what it's worth, amateur radio operators already have specialized rules and techniques for speech, to improve clarity over a muffled noisy analog radio channel.

Going as far as using trinary for on the fly data encoding .

Re: Google open-sources the Lyra audio codec

#110

Post by andrepd »

LeoPanthera wrote: post #88
throwaway81523 wrote: post #84

Another reason for end-to-end speech encryption: to keep your cleartext voice signal away from these overaggressive codecs changing the words. I can understand the need for a super low bandwidth codec on top of Mt. Everest, but 64 kbit PCM was good enough for our grandparents' landlines (or 13 kbit GSM for their mobiles) and it's good enough for us.

What a spectacular failure of imagination. Why change anything ever, right? I supposed dial-up modems were good enough for you too. Everyone is imagining that codecs like this will "change your words" but no-one has provided examples of that actually happening . I don't believe it.

There are examples posted elsewhere in this thread, although from a beta version.

Also, Opus already blows any requirements, either in terms of latency or in terms of size. Adding such unreliability for minimal gain seems foolish.

Post reply on HN