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

131–140 of 145 posts

Re: Google open-sources the Lyra audio codec

#131

Post by ehsankia »

dang wrote: post #77

Recent past threads on this: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate - https://news.ycombinator.com/item?id=26300229 - March 2021 (198 comments) Lyra: A New Very Low-Bitrate Codec for Speech Compression - https://news.ycombinator.com/item?id=26279891 - Feb 2021 (25 comments) Is there significant new information here? https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so... Edit: it…

> Is there significant new information here?

The fact that it's not open-source? The blog post is posted today and from Google themselves, so I assume there's new information.

Re: Google open-sources the Lyra audio codec

#132

Post by jbluepolarbear »

dqv wrote: post #26
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 already happens with existing compression algorithms. Certain vowel sounds get collapsed, so someone will say, for example, "66" and it will come out on the other side as "6". Very annoying because you can't exactly coach a layperson on how to talk "the right way" to not trigger this vowel collapse.

I don’t know if it’s improved over the last 6 months, but Zoom sucks for Native Spanish speakers speaking English. Like zoom would not pick up the J/H sound at all on English words.

Re: Google open-sources the Lyra audio codec

#133

Post by ehsankia »

taneq wrote: post #105
beagle3 wrote: post #95

Earlier quoted context omitted.

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.

At the end of the day, it all comes to using the right tool for the job, and this is just another codec in your toolbox.

This is no different than using, for example, a probabilistic algorithm to solve some NP-hard problem in your real world software. As long as you understand the limitations, I don't see an issue with using an algorithm that has a small non-significant (for your use-case) rate of failure. I would definitely not use this to communicate with the space station, but in the right context (Google Duo, low bandwidth), it's the perfect tool.

Re: Google open-sources the Lyra audio codec

#135

Post by beagle3 »

ampdepolymerase wrote: post #113
beagle3 wrote: post #95

Earlier quoted context omitted.

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

It would be curious how the court would interpret this. Just wait for the next high profile SEC shakedown.

That’s probably meant for another thread

Re: Google open-sources the Lyra audio codec

#137

Post by miohtama »

nl wrote: post #123
posguy wrote: post #116

Earlier quoted context omitted.

> It is over 6Kbps Opus[1]. The overhead from packet headers to send data every 40ms is 9.6kbps, is the difference between 12.6Kbps and 17.6Kbps meaningful at that point? We are sending the same number of packets, likely with the same packet loss rate. > A RaspberryPi Zero will provide more than sufficient power for Lyra A Raspberry Pi Zero can't run Lyra, as the proprietary math kernel is only offered in compiled fo…

> is the difference between 12.6Kbps and 17.6Kbps meaningful at that point It is when you are sending video as well. One of the stated purposes of this work is to enable video conferencing over 56Kbps dial up modems. > A Raspberry Pi Zero can't run Lyra, as the proprietary math kernel is only offered in compiled form for x86-64 and android-arm64 How annoying! Still - the point is that hardware capability isn't likely…

It is mentioned in other comments that the math kernel will be opened.

Re: Google open-sources the Lyra audio codec

#138

Post by regularfry »

skybrian wrote: post #48
te0006 wrote: post #41

"Please note that there is a closed-source kernel used for math operations that is linked via a shared object called libsparse_inference.so. We provide the libsparse_inference.so library to be linked, but are unable to provide source for it. This is the reason that a specific toolchain/compiler is required.* - README

Yes, that will have to be removed as part of the effort of porting it to new platforms.

What's in it? Is there anything in there that's likely to be generally useful, or is it all Lyra-specific?

Re: Google open-sources the Lyra audio codec

#139

Post by londons_explore »

herodoturtle wrote: post #73
londons_explore wrote: post #61

Google misses the mark here... Bad internet connectivity in the developing world isn't "only 56kbps" as some people think. It's "random bursts of fast with random 30 second gaps of no connectivity at all". It's routed through 3 layers of proxies and firewalls which block random stuff and not others, while disconnecting long running connections. Oh, and it'll be expensive per MB. To that end, Lyra helps with the expen…

Heya, please could you unpack your reasoning a little bit more? You said: > WhatsApp is already wildly popular in most of the developing world for mostly this reason. I can't speak for the majority of the developing world, but here in South Africa, WhatsApp is indeed the predominant communications app. That being said, WhatsApp voice calls are also used here quite a bit. So with that in mind, and reading from the art…

Lyra is a good candidate for replacing the protocol already used in Whatsapps voice calls. The binary size of Whatsapp matters, so it would depend on Lyra not requiring a multi-megabyte neural net too. The 40 millisecond extra enforced delay might have a negative impact on user experience.

It might be a good candidate for use in the voice message feature of whatsapp. That feature doesn't require low latency audio, so there might be even better compression schemes that use forward and backward compression techniques.

Re: Google open-sources the Lyra audio codec

#140

Post by londons_explore »

setr wrote: post #75
londons_explore wrote: post #61

Google misses the mark here... Bad internet connectivity in the developing world isn't "only 56kbps" as some people think. It's "random bursts of fast with random 30 second gaps of no connectivity at all". It's routed through 3 layers of proxies and firewalls which block random stuff and not others, while disconnecting long running connections. Oh, and it'll be expensive per MB. To that end, Lyra helps with the expen…

In the middle east I noticed a baffling-to-me usage of whatsapp: people were simply exchanging voice messages back and forth instead of calling. [0] Presumably for exactly the reason you've stated. [0] I later tried it myself with a friend, but you end up losing the benefits of both worlds -- you can't search or review old messages effectively (as you would text), and its significantly slower than calling.

There is a gap in the market for "searchable" voice clips - ie. auto transcribed to text, and allowing the user to see the text or hear the message.
Post reply on HN