libgsmhr1 RxFE: store CN R0+LPC separately from speech In the original GSM 06.06 code the ECU for speech mode is entirely separate from the CN generator, maintaining separate state. (The main intertie between them is the speech vs CN state variable, distinguishing between speech and CN BFIs, in addition to the CN-specific function of distinguishing between initial and update SIDs.) In the present RxFE implementation I initially thought that we could use the same saved_frame buffer for both ECU and CN, overwriting just the first 4 params (R0 and LPC) when a valid SID comes in. However, I now realize it was a bad idea: the original code has a corner case (long sequence of speech-mode BFIs to put the ECU in state 6, then SID and CN-mode BFIs, then a good speech frame) that would be broken by that buffer reuse approach. We could eliminate this corner case by resetting the ECU state when passing through a CN insertion period, but doing so would needlessly increase the behavioral diffs between GSM 06.06 and our version. Solution: use a separate CN-specific buffer for CN R0+LPC parameters, and match the behavior of GSM 06.06 code in this regard.

The present state of gsm-codec-lib Hg repository is a Work In Progress
with respect to addition of libgsmhr1, a WIP library seeking to implement
GSM-HR codec in a way that fits into the grander vision of Themyscira Wireless.

In the present WIP state absolutely NO commitments are being made with regard
to API stability - the current WIP API can change at any moment!

As a reminder, NO binary packages or build recipes should be made from this
WIP state!  If you don't need GSM-HR codec, please use the latest stable
release tarball; if you do need GSM-HR codec, please wait until libgsmhr1
reaches version 1.0.0 per SemVer.

If you need some GSM-HR functions (e.g., frame packing and unpacking) and
cannot wait for libgsmhr1 version 1.0.0, the acceptable interim solution is to
lift those individual C modules out of this repository and plop them directly
into your own code - doing so would be more acceptable than making installable
packages out of the present WIP.