FreeCalypso > hg > gsm-codec-lib
view doc/EFR-testing @ 242:f081a6850fb5
libgsmfrp: new refined implementation
The previous implementation exhibited the following defects,
which are now fixed:
1) The last received valid SID was cached forever for the purpose of
handling future invalid SIDs - we could have received some valid
SID ages ago, then lots of speech or NO_DATA, and if we then get
an invalid SID, we would resurrect the last valid SID from ancient
history - a bad design. In our new design, we handle invalid SID
based on the current state, much like BFI.
2) GSM 06.11 spec says clearly that after the second lost SID
(received BFI=1 && TAF=1 in CN state) we need to gradually decrease
the output level, rather than jump directly to emitting silence
frames - we previously failed to implement such logic.
3) Per GSM 06.12 section 5.2, Xmaxc should be the same in all 4 subframes
in a SID frame. What should we do if we receive an otherwise valid
SID frame with different Xmaxc? Our previous approach would
replicate this Xmaxc oddity in every subsequent generated CN frame,
which is rather bad. In our new design, the very first CN frame
(which can be seen as a transformation of the SID frame itself)
retains the original 4 distinct Xmaxc, but all subsequent CN frames
are based on the Xmaxc from the last subframe of the most recent SID.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Tue, 09 May 2023 05:16:31 +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.