lyra V2 3200bps codec support

[philipag]

The Lyra v2 codec supports 20ms 3200bps frames just like codec 2 so it would be a drop-in codec 2 replacement for that mode. A cursory look indicates that lyra V2 audio quality is considerably higher than codec 2 at this bit rate. Also the source code is c++ so easy to integrate with M17.

It's just a thought but this would put audio quality far above what DMR and the other protocols provide - the type of advantage that could propel M17 into the mainstream.

[sp5wwp]

Have you tried coding speech with Lyra in realtime on an MD380-class handheld?

[philipag]

No but V2 of the codec is fairly efficient and may well be possible on the 100-400 MHz arm cores we see in radios today. Of course this is something that needs to be evaluated.

[sp5wwp]

Interesting. Try it out and tell us if it's feasible.

[philipag]

I don't have a radio to test this on. I won't be able to work on this now - just wanted to mention it as an interesting option.

In the future I may evaluate this for another unrelated project and will report back if I do.

[philipag]

Lyra V2 appears to run about 35x realtime on a modern phone core so my guess is that a 400Mhz Arm7 core will easily be fast enough. The STM32F405VG @ 168MHz would probably also be able to handle it but that would require testing.

Some useful information on embedded Lyra V1 which is much slower: https://stackoverflow.com/questions/71415999/google-lyra-on-bare-metal-microcontroller

[kc1awv]

Moving this to Discussions, as it's not really an issue.

[tarxvftech]

I suspect it'll be difficult to run in realtime on the MD-380 while also doing other things - but the dual core ESP32s will probably have no trouble, if I had to guess. Maybe this could be something for M17.2 or whatever versioning scheme gets used.

As I remember it, old Lyra didn't open source everything, only some parts. This looks like they have now opened everything for v2?

Something also to keep in mind - at least some people flat-out can't understand Lyra1, my dad is one of them. Play any random Lyra1 example to him and something there just doesn't work. For hams we might consider large-ish scale A/B testing of codecs to see which actually perform best for ham usage. I'm excited to see if Lyra2 is better.

Make sure when you do comparison testing you listen to the Lyra version first before the raw version, else your brain can trick you more easily.

[philipag]

I believe Lyra V2 is now completely open sourced. The project is also emphasizing performance enhancements and even though embedded targets are not yet directly supported, the underlying TensorFlow.Lite library is embedded-friendly. One big aspect to adapting Lyra to M17 might be to remove stdlib dependencies like malloc if it has those. TensorFlow.Lite already supports stdlib-free embedded systems I believe.

Yes, the only way to really compare codec 2 with Lyra V2 is by using the same samples. The Codec 2 samples I have heard are based on very low bandwidth original samples while the Lyra V2 samples are higher fidelity in an Irish accent. But based on what I heard from the existing samples it seems Lyra V2 is much better sounding and more intelligible. The thing that is most exiting is the fact that the audio no longer needs to be cellular style quality of 8KHz. It can be 16KHz!

[SmittyHalibut]

What is the proposal here?

1. Add it to the protocol doc (this was originally submitted to M17_spec after all)? If so, I see no reason not to add it to the doc, and leave implementation up to the implementers. The protocol should be general enough to allow for expansion like this in the future.
2. Implement it in the current development platforms? If so, then, yeah, this discussion is relevant.

Really, it comes down to whether this is a "now" request or a "someday" request. I think it's valid as a "someday" request, and should probably come with a pull-request as a "now" request. :-)

[philipag]

For when this is something to be defined or implemented here is my 2 cents (from someone not familiar with the M17 code base so forgive my ignorance):

• The protocol and architecture should allow switching between codecs so that it is easy to deploy new codecs with newer M17 radios.
• The codec interface could be architected such that it is possible to even add closed-source codecs to a build.
• If Lyra Vx or some other newer codec is implemented at some point, then likely all radios will be able to decode Lyra while only those with sufficient hardware can encode. This means that newer radio hardware could send audio with Lyra encoding and even an older radio would be able to decode it. But transmission from the older radio would continue to use a lighter codec. The nice thing about this is that there will never be any backwards compatibility problems with older radios as long as they are updated to firmware which includes the latest codec decoders. And for when firmware updates are not possible for an older radio, there could be a contact specific setting to force a less complex encoder for transmit (for backwards compatibility with these non-upgradeable radios).

[philipag]

Reading a bit more about Lyra V2 it seems that in addition to stdlib dependencies, the memory footprint may be a blocking issue for embedded applications. I did not find specifics for the current version but the requirements may currently be well beyond the stm32.

[SmittyHalibut]

Again, is this request about adding it to the Spec, which will outlast current hardware limitations? Or is it about implementing on current development hardware?

If it's about adding it to the Specification, current hardware limitations shouldn't prevent that. Hardware will only get better and someday, Lyra V2 will be possible. If there isn't anything else preventing it from being added to the spec (there might be; I really don't know), then I see no reason not to add it, and assign it a CODEC number in the protocol.

[philipag]

@SmittyHalibut It would be nice to have now but I think there will be considerable implementational complexity and it will be better to wait until the Lyra code base is more embedded-friendly.