FreeCalypso > hg > gsm-codec-lib
view doc/EFR-testing @ 581:e2d5cad04cbf
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.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Thu, 13 Feb 2025 10:02:45 +0000 |
| parents | 1e8569000049 |
| children |
line wrap: on
line source
When it comes to codec libraries, testing for correctness is essential, and EFR is no exception. There is a set of EFR encoder and decoder test sequences published by ETSI in ts_100725v050200p0.zip (GSM 06.54), and our suite of tools includes gsmefr-etsi-enc and gsmefr-etsi-dec test programs that operate on the representation formats used by these test sequences. Because these test programs are based on libgsmefr EFR_encode_frame() and EFR_decode_frame() functions, seeing gsmefr-etsi-enc produce output that matches official ETSI *.cod files proves that libgsmefr encoder is correct, and seeing gsmefr-etsi-dec produce output that matches official ETSI *.out files proves that libgsmefr decoder is correct. For debugging, we also have gsmefr-cod-parse and gsmefr-dec-parse utilities that parse ETSI *.cod and *.dec file formats and dump their content in human-readable form similar to gsmrec-dump. Please note that all ETSI test sequence file formats are endian-dependent: their original programs read and write 16-bit words in the local machine's native byte order, and whenever you are working with published test sequence files, you have to check to see if they are BE or LE. Our gsmefr-etsi-{enc,dec} and gsmefr-{cod,dec}-parse programs support both byte orders; the default is LE (matching the main parts of ts_100725v050200p0.zip), or you can select BE with -b option.