[maep]

I remember seeing published numbers based on instrumented code, but could not find it.

I did a quick test with the Google implementation (https://github.com/google/liblc3) which is about 2x faster than Opus. To be honest, I expected a bigger difference, though it's just a superfical test.

A few things that also might be of relevance why they picked one over the other:

  - suitability for DSPs
  - vendor buy-in
  - robustness
  - protocol/framing constraints
  - control

[out_of_protocol]

Thanks for checking it, appreciated

- Well, 2x is nothing to write home about.

- DSP-compatibility probably considered but never surfaced as a reason, so hard to guess investigation results. + Pricing and availability of said DSP modules

- Robustness - well, that's one of the primary features of opus, battle tested by WebRTC, WhatsApp etc. (including packet loss concealment (PLC), Bit-Rate Redundancy (LBRR) frames)

- Algorithmic delay for opus is low, much lower than older BT codecs, so that definitely wasn't a deal breaker

- Ability to make money out of standard is definitely important thing to have

[maep]

If used in a small device like a hearing aid, a 2x factor can have a significant impact on battery life.

VoIP in general experiences full packet loss, meaing if a single bit flips the entire packet is dropped. For radio links like Bluetooth it's possible to deal with some bit flips without throwing the entire packat away.

Until 1.5 Opus PLC was in my opinion it's biggest weakness, compared to other speech codecs like G.711 or G.722. A high compression ratio causes bit flips to be much more destructive.

As for making moeny, Bluetooth codecs have no license fees.

[derf_]

> For radio links like Bluetooth it's possible to deal with some bit flips without throwing the entire packat away.

Opus was intentionally designed so that the most important bits are in the front of the packet, which can be better protected by your modulation scheme (or simple FEC on the first few bits). See slide 46 of https://people.xiph.org/~tterribe/pubs/lca2009/celt.pdf#page... for some early results on the position-dependence of quality loss due to bit errors.

It is obviously never going to be as robust as G.711, but it is not hopeless, either.