Google's New Lyra Voice Codec + AV1 Aim For Video Chats Over 56kbps Modems In 2021

[IgorCC]

"Why aren't they comparing this to LPCNet?"

They compare it to codecs which people most familiar with (Opus and Speex).
Also both, LPCNet and Lyra, borrow some principles from Google proof of concept, Wavenet https://deepmind.com/blog/article/wa...odel-raw-audio

It won't be quite right to compare LPCNet or Wavenet vs Lyra.
LPCNet was also more "proof of concept" with somewhat high hardware requirements (at least Cortex A-75) while Lyra should be fine with pretty every mid-range phone.
And Wavenet's hardware requirements aren't met by mobile devices.

[Svyatko]

56kbps dial-in modem

- dial-up, not dial-in.

With V.90 you will get up to 56 kbit/s download + up to 33.6 kbit/s upload.
With V.92 you will get up to 40-56 kbit/s download + up to 48 kbit/s upload.
And this is with the best conditions.

https://en.wikipedia.org/wiki/Modem#...s_technologies
https://en.wikipedia.org/wiki/Modem#...56k_(V.90/V.92)
(problems with ")" - last bracket)

The high upload speed was a tradeoff. 48 kbit/s upstream rate would reduce the downstream as low as 40 kbit/s due to echo effects on the line. To avoid this problem, V.92 modems offer the option to turn off the digital upstream and instead use a plain 33.6 kbit/s analog connection in order to maintain a high digital downstream of 50 kbit/s or higher.

ILL Google engineers are too young for dial-up tech.
Lyra codec + AV1 video conferencing is good for 2G, not for dial-up. With ADSL/VDSL/etc. you will get much higher speeds than 56 kbit/s.

[oiaohm]

They compare it to codecs which people most familiar with (Opus and Speex).
Also both, LPCNet and Lyra, borrow some principles from Google proof of concept, Wavenet

It won't be quite right to compare LPCNet or Wavenet vs Lyra.
LPCNet was also more "proof of concept" with somewhat high hardware requirements (at least Cortex A-75) while Lyra should be fine with pretty every mid-range phone.
And Wavenet's hardware requirements aren't met by mobile devices.

LPCNet is not exactly a proof of concept its targeted at different market to Lyra. https://freedv.org/ LPCNet was design for hamradio where CPU processing is no where near as restricted as you can use full blown laptops if required. But radio bandwidth is more restricted so the bit rate is way more restricted. Yes the 56kbps is in fact a lot of bandwidth when you are talking hamradio use case.

https://www.rowetel.com/?p=6639

Note the example here of LPCNet for hamradio 1733 bits/s 56000/2000 so Lyra targeting that it can use roughly 28 times more bandwidth than LPCNet for hamradio can.

Lyra reduces the amount of compression to reduce the amount of cpu processing. Lyra is not suitable for the hamradio use case its needing much bandwidth in a lot of cases.

Codec2 and LPCNet are both in your ultra light on bandwidth class of voice compression where you operation bandwidth you are looking for is 3kbps or less. These are in the class that you need to get a certificates at times for exporting a possible weapon of mass destruction due to their possible military usages for command and control of weapons of mass destruction.

Lyra at 56Kbps is not classified as a possible weapon. Yes Opus and Speex are also not weapon class either.

Its a surprise to some people that you can make a audio codec that is technically a weapon by different countries laws.

Lyra codec + AV1 video conferencing is good for 2G, not for dial-up. With ADSL/VDSL/etc. you will get much higher speeds than 56 kbit/s.

This idea of ADSL speed is not exactly true.

https://www.hardwaresecrets.com/how-the-adsl-connection-works/

Little known fact about adsl is that each channel is 56Kbit/s if you are on a horrible line and I do mean horrible like you can have your adsl 1/2 connection down to a single ADSL channel so back to 56kbit/s. Also another way you can have not very much ADSL is the party line setup. Yes fun little fact with ADSL 1 and 2 is that you can put more than 1 modem on a single phone line for different users.

The bare min ADSL connection that can work is 56kbit/s up and down. There is some PPP overhead so the transfer is less than that in the worst case. Some adsl1 and adsl2 modems can in fact do bandwidth allocation based on ADSL channels. So items going out X port get Y ADSL channels worth of bandwidth.

56Kbit/s connection makes sense if your target user is ADSL. There are still places around the world with 56 kbit/s is classed as a functional internet connection so if you ADSL/VDSL.... is only giving you 56 kbit/s you have been provided with service like it or not by many countries laws. Yes ADSL/VDSL the bare min connection that works is 56kbit/s you really hope to get better than that but not everyone does and by law of their country some people just have to accept the bare min. Yes your adsl provider at the DSLAM can lock you to 1 channel up and 1 channel down no matter how good or bad the line is when its the law of the country they can get away with it.

[IgorCC]

LPCNet was design for hamradio

LPCNet wasn't design for hamradio. The first paper from authors were released is here https://arxiv.org/abs/1810.11846 . Please observe not a single word about "hamradio" and later author compares LPCNet to classic internet audio codecs.

Note the example here of LPCNet for hamradio 1733 bits/s 56000/2000 so Lyra targeting that it can use roughly 28 times more bandwidth than LPCNet for hamradio can.

I don't know where You got 56 kbps from requierement for Lyra but it doesn't require it. Required BW is much less.

If we talk about VoIP (not hamradio) which is 90%+ people talk about here then an overhead for Lyra's 3 kbps 40ms packet will be ~ 8kbps, so the final tramsmitted rate would (8+3), 11 kbps. Same goes for LPCNET , Codec2 or any other codec used as VoIP in internet or private network.

So Codec2 doesn't expose any advantage over LPCNet/Lyra/Satin in VoIP usecase.

[oiaohm]

LPCNet wasn't design for hamradio. The first paper from authors were released is here https://arxiv.org/abs/1810.11846 . Please observe not a single word about "hamradio" and later author compares LPCNet to classic internet audio codecs.

https://www.rowetel.com/wordpress/?p=6482 Its not in the first paper but this is under 1 month. Features from codec2 go into LPCNet. Yes this is 11 November 2018 that paper 28 Oct 2018 first released. The revisions to that paper 19 Feb with improvements to the LPCNet code trace to FreeDV for hamradio.

I don't know where You got 56 kbps from requierement for Lyra but it doesn't require it. Required BW is much less.

That is the google stated target for future development Lyra.

https://ai.googleblog.com/2021/02/lyra-new-very-low-bitrate-codec-for.html

Pairing Lyra with new video compression technologies, like AV1, will allow video chats to take place, even for users connecting to the internet via a 56kbps dial-in modem.

There target is 56kbps modem worth of bandwidth. This is larger than you hamradio bandwidths. You hamradio bandwidths will barely support audio there is no room for a video chat in the tight areas.

If we talk about VoIP (not hamradio) which is 90%+ people talk about here then an overhead for Lyra's 3 kbps 40ms packet will be ~ 8kbps, so the final tramsmitted rate would (8+3), 11 kbps. Same goes for LPCNET , Codec2 or any other codec used as VoIP in internet or private network.

So Codec2 doesn't expose any advantage over LPCNet/Lyra/Satin in VoIP usecase.

Except that is not the google voip use case. When what you are doing is video chat the smaller you can get the audio the more space you have for the video bit of the signal.

Hamradio case and the google voice+video cases are horrible different.

Google voice/video target is 56kbps moden speeds so this means Lyra does not have to have as tight of restrictions like it possible to steal some of the bandwidth from the video for the audio because something does not compress well.(this is not going to fly with the ham usage case)

Hamradio you need to get the result small because you have overheads in other ways big one is the error corrections you have to add to digital hamradio at times to over come radio noise. So you might have a 2kbps but you are in fact needing to send 4 times that so it error corrects on the other end into something useful. This leads to the Hamradio case being smaller the better. Ramping speed up and down is not really possible when building the codec for ham.

So I really do expect to see LPCNET and Lyra basically split away from each other. Some of the hamradio optimisations for size that do cost audio quality at times and add extra cpu processing that are in LPCNet will make no sense in the Google use case for Lyra because you have the 22x bandwidth speed to play with to cover some overhead here or there. Yes not having those optimisations to keep the size down as Lyra is missing makes no sense in the hamradio usage case because the hamradio bandwidth can be bugger all few bits of bandwidth need here or there can basically break the ability to setup a hamradio connection that is stable.

Its been known for a while that codecs designed for hamradio/military radio are not ideal for your general voip and your codecs for general voip really don't work in you true must be sub 3kbps constantly for hamradio/milradio. Its the difference between a constant rate codec and a multi rate one. Multi rate can give better quality and not suitable on hamradio.

Reason why Lyra, Opus and speex are being compared to each other by google developer is they are all multi rate codecs. LPCNET and Codec2 in hamradio usage are constant rate codecs. Not really a fair compare putting a constant rate against a multi rate due to the different optimisations you do in the constant rate vs multi rate.

Hamradio and voip are truly two different problem spaces. Its really simple to forgot they are and end up mixing stuff in that suites the hamradio case.