Live data from Hacker News

Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

cnx-software.com

61–70 of 207 posts

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#61
post #39

What I want to know is whether Lyra takes any longer to encode than the alternatives. Because as far as I can tell, nobody cares in the slightest about latency. Phone calls are getting to be like writing postcards to each other. Speak in a whole paragraph. Wait several seconds for the latency to clear. Then the other party responds with a whole paragraph, waits several seconds for the latency to clear... Improvements…

This is a fantastic question. I agree with you that we're slowing boiling the frog (and the frog is ourselves) in accepting more and more latency in our real-time communications.

I think the answer for Lyra is that latency is a concern, but maybe at this stage not as much of a concern as it could be. I'm only guessing, though based on this [0]:

> The basic architecture of the Lyra codec is quite simple. Features, or distinctive speech attributes, are extracted from speech every 40ms and are then compressed for transmission.

That sounds like the minimum frame size for Lyra is 40ms. For Opus (the audio codec used for most WebRTC applications), the default frame size is 20ms [1], and most implementations support frame sizes of 10ms [2].

Of course, your favorite web browser might not default to 20ms frames for Opus. And by "most implementations" I meant Google Chrome. :-)

[0] https://ai.googleblog.com/2021/02/lyra-new-very-low-bitrate-...

[1] https://tools.ietf.org/html/rfc7587#section-6.1

[2] https://chromium.googlesource.com/external/webrtc/+/HEAD/mod...

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#62

How come the clean reference wav file is 168KB, while the clean Lyra (@3kbps) wav file is significantly larger at 328KB?

Since a browser can't play lyra I think they took the lyra output and put it inside something lossless like a 44kHz stereo wav so that people can listen to it.

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#63
post #47
post #14

Earlier quoted context omitted.

Isn‘t VoIP at such low data rates already dominated by the overhead of UDP, IP and whatever lower layer? Multiplexing it with a low-bandwidth video stream would be possible, though. I was thinking this could be most relevant for something like digital wireless transmissions.

G.729 is 21-30kbps with transport overhead, depending on a few factors. So shaving off 5kbps would still be meaningful. Or better quality at the same bandwidth might enable in-band DTMF or fax, neither works on G.729 now.

In-band fax will certainly not work over a lossy voice codec, unless your fax modem is able to mimic human speech patterns.

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#64

Earlier quoted context omitted.

Yeah, with Codec 2 setting the gold standard, I don't find this very impressive. I find this more intelligible at one-third of the Lyra bitrate: http://www.rowetel.com/downloads/codec2/hts2a_1300.wav Codec 2 does a better job of isolating the parts of sound which are most necessary to intelligible speech, without necessarily caring too much about preserving the original qualities of the speaker's voice or environment…

I had to listen to your wav sample 4 times before understanding what it was saying... To me, that isn't intelligible... Perhaps with practice one could learn to understand it, but that isn't really what I want from my audio codec.

The biggest challenge with evaluating all of these, is that once you've listened to a comprehensible version of one of these samples, they all sound more intelligible. I had problems with the example too. After hearing the original it's now easy. It makes it really hard to properly assess the intelligibility for developers without decent sized panels of people to help evaluating them.

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#65
post #55

Earlier quoted context omitted.

I had the pleasure of using a real landline just before the pandemic. Honest wire-to-wire connection between two ranches, so no silly VOIP steps between. It was fantastic. You don't appreciate how much latency is destroying our ability to communicate verbally until you go back to the old way. One example is arguing. It's no wonder people used to be able to argue with one another on a telephone. You could raise your v…

A cell phone tbh, is about the same latency as a landline in most end to end call circumstances. Latency only really is noticeable when better than 600ms. (And only a real problem over 1000)

I think latency is noticeable at even lower values. As a basic example, try to sing a song with someone over a voice call. Consider using Airpods or similar bluetooth headphones to make it more apparent.

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#66

How come the clean reference wav file is 168KB, while the clean Lyra (@3kbps) wav file is significantly larger at 328KB?

When they converted back to wav from Lyra, they used a 32 bit 16 Khz wav instead of 16 bit 16 Khz wav like the source. The size of the Lyra file is almost exactly 2x as big as the reference.

Note that this isn't cheating in any way, the source is the source, so it's just a quirk from their conversion process. Probably the tooling around Lyra is pretty rudimentary and the decoder could only output a 32 bit file.

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#67
post #55

Earlier quoted context omitted.

I had the pleasure of using a real landline just before the pandemic. Honest wire-to-wire connection between two ranches, so no silly VOIP steps between. It was fantastic. You don't appreciate how much latency is destroying our ability to communicate verbally until you go back to the old way. One example is arguing. It's no wonder people used to be able to argue with one another on a telephone. You could raise your v…

A cell phone tbh, is about the same latency as a landline in most end to end call circumstances. Latency only really is noticeable when better than 600ms. (And only a real problem over 1000)

I disagree with these numbers, in general. Though of course "noticeable" is subjective and varies by use case as well as by person.

For many people, end-to-end audio latency in a 1:1 conversation becomes noticeable/annoying at 200ms. And in a multi-participant conversation, talking over each other becomes noticeably more common even at 100ms compared to 50ms.

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#68
post #55

Earlier quoted context omitted.

I had the pleasure of using a real landline just before the pandemic. Honest wire-to-wire connection between two ranches, so no silly VOIP steps between. It was fantastic. You don't appreciate how much latency is destroying our ability to communicate verbally until you go back to the old way. One example is arguing. It's no wonder people used to be able to argue with one another on a telephone. You could raise your v…

A cell phone tbh, is about the same latency as a landline in most end to end call circumstances. Latency only really is noticeable when better than 600ms. (And only a real problem over 1000)

Imagine trying to have a face-to-face conversation with 600ms of latency...

Re: Lyra audio codec enables high-quality voice calls at 3 kbps bitrate

#69
post #61
post #39

What I want to know is whether Lyra takes any longer to encode than the alternatives. Because as far as I can tell, nobody cares in the slightest about latency. Phone calls are getting to be like writing postcards to each other. Speak in a whole paragraph. Wait several seconds for the latency to clear. Then the other party responds with a whole paragraph, waits several seconds for the latency to clear... Improvements…

This is a fantastic question. I agree with you that we're slowing boiling the frog (and the frog is ourselves) in accepting more and more latency in our real-time communications. I think the answer for Lyra is that latency is a concern, but maybe at this stage not as much of a concern as it could be. I'm only guessing, though based on this [0]: > The basic architecture of the Lyra codec is quite simple. Features, or…

Google Chrome has a latency of 20ms to just repeat back audio on the local device.

That is, with no networking, and no processing, it takes 20ms for any information to from microphone back out to speakers.

Post reply on HN