# HG changeset patch # User Mychaela Falconia # Date 1670729121 0 # Node ID 4af99bf8671a0964aea7a081853f5278106cfb9c # Parent 6fd49f73b0251dec35ef2c19a144f52992cf40f3 doc/EFR-rationale: add future roadmap section diff -r 6fd49f73b025 -r 4af99bf8671a doc/EFR-rationale --- a/doc/EFR-rationale Sun Dec 11 00:56:17 2022 +0000 +++ b/doc/EFR-rationale Sun Dec 11 03:25:21 2022 +0000 @@ -80,3 +80,20 @@ for encoder state and another unified struct for decoder state - but the problem of poor performance (significantly worse than opencore-amrnb) still remains for now. + +Future roadmap +============== + +If someone is implementing a DSP vocoder block for a GSM MS or a network-side +speech transcoder that needs to support all standard GSM codecs, at some point +they will need to implement both EFR and AMR. Given the close relation between +these two codecs (they are not perfectly compatible as we started out saying, +but they are still very closely related), keeping two entirely separate library +implementations for AMR and EFR will be very inefficient in the long run, and a +nightmare to get them to perform equally well. It seems to me (Mother Mychaela) +that the correct solution will be to produce a single codec library that +implements both AMR and EFR, probably by starting with an AMR library and +extending it with special modes to handle those aspects where EFR differs. It +is my forecast that we are going to end up doing something along these lines in +Themyscira - but it will be much later down the road; for the time being, our +initial version of ThemWi will only support FR and EFR, but not AMR.