FreeCalypso > hg > gsm-codec-lib

comparison doc/AMR-EFR-performance @ 487:cd1f0fa936cc

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/AMR-EFR-performance: new article
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 20 May 2024 21:53:11 +0000
parents
children
comparison
equal deleted inserted replaced
486:f35c8fd9ceba 487:cd1f0fa936cc
1 Performance of libgsmefr and libtwamr, compared to competition
2 ==============================================================
3
4 Both libgsmefr and libtwamr are based on reference C code from ETSI/3GPP:
5 libgsmefr is a librified version of GSM 06.53 reference code, and libtwamr is a
6 librified version of TS 26.073 reference code. Both of those reference sources
7 were officially presented as simulations, not as production code for running on
8 general-purpose x86 servers implementing transcoding MGW functionality, and the
9 code is extremely inefficient.
10
11 The problem of poor performance (taking too much CPU percentage per transcoded
12 call) would not be so acute if Themyscira GSM codec libraries existed in a
13 vacuum without competition - but we do have a competitor in the form of
14 libopencore-amrnb, part of the slightly larger opencore-amr package. Just like
15 libtwamr, that library is a derivative work based on the original AMR C code
16 from 3GPP, but by a more circuitous route: first PacketVideo created an
17 implementation of AMR for Android based on 3GPP reference code, then the
18 creators of opencore-amr took PV's Android implementation (named OpenCORE) and
19 ported it from Android to standard Unix/Linux userspace.
20
21 Aside from its peculiar genealogy, there are practical problems with
22 libopencore-amrnb that made it unattractive for Themyscira Wireless, and thus
23 created the impetus for producing the present alternative:
24
25 * That library implements only AMR and not EFR, whereas for ThemWi good support
26 for EFR is a higher priority than good (or any) support for AMR.
27
28 * The idea of reshuffling bits in the manner of our gsm-amr2efr and gsm-efr2amr
29 hack-utilities (see AMR-EFR-conversion article) in order to implement "poor
30 man's EFR" via libopencore-amrnb was considered, but then rejected on
31 philosophical and aesthetic grounds: it feels philosophically wrong to
32 reshuffle bits in the application wrapper only to have internal code within
33 the library shuffle them back into the natural order of codec parameters.
34
35 * Like any AMR-and-not-EFR library, libopencore-amrnb cannot grok EFR SID
36 frames. Therefore, an implementation of "poor man's EFR" using that library
37 would have to operate with DTXu disabled, needlessly burning battery capacity
38 in the MS.
39
40 * Even for "pure" AMR and not EFR, libopencore-amrnb exhibits one serious
41 defect: it omits the in-band homing feature in both the encoder and the
42 decoder, even though this feature is mandatory per 3GPP specs. (It is not
43 clear if this removal of homing functions was the work of PacketVideo in the
44 world of Android, or if it happened at the time of subsequent opencore-amr
45 port to standard Unix/Linux userspace.) Furthermore, because the interface
46 wrapper module of libopencore-amrnb does not expose any state reset functions,
47 it is impossible to implement the homing feature externally to the library.
48 This lack of homing makes it impossible to test libopencore-amrnb against the
49 full set of 3GPP test sequences for AMR.
50
51 In the present time, as of this release of Themyscira gsm-codec-lib, libgsmefr
52 is intended for production use while libtwamr is intended for lab use only,
53 matching test sequences and modeling bit-exact operation of other people's
54 network elements in reverse engineering workflows. Based on this difference in
55 applicability to production, more work has been put into improving performance
56 of libgsmefr compared to libtwamr. Libgsmefr version 1.1.0 exhibits
57 approximately 2x performance improvement over the original version, but it is
58 still significantly slower than libopencore-amrnb.
59
60 The following performance numbers were obtained on Mother Mychaela's development
61 laptop, Intel Core2 Duo P8600 CPU @ 2.40 GHz, running 32-bit version of
62 Slackware, i.e., running only i686 code and not x86_64 despite the CPU having
63 the 'lm' feature. All tests involve encoding TEST4.INP sequence from GSM 06.54
64 set (301 frames in total, 6.020 s audio duration), then decoding the output of
65 the encoder run.
66
67 Implementation Encoding time Decoding time
68 ---------------------------------------------
69 libgsmefr 183 ms 23 ms
70 libtwamr 359 ms 52 ms
71 opencore-amr 53 ms 13 ms
72 libgsmfr2 (FR) 13 ms 6 ms
73
74 FRv1 encoding and decoding of the same TEST4.INP was included in the test in
75 order to convince ourselves that FRv1 is not in any need of performance
76 optimization. In a network deployment that generally prefers EFR over FRv1,
77 almost all calls between a local GSM MS and the outside world (PSTN) will
78 involve the EFR transcoder rather than FRv1. If on rare occasion the network
79 selects FRv1 instead of EFR because the subscriber is using a super-old
80 non-EFR-capable handset (or has artificially restricted the speech version list
81 to FRv1 only), there will be some CPU cycles saved "for free" by using the much
82 less computationally expensive FRv1 codec - but CPU capacity planning for the
83 transcoding MGW has to be based on EFR performance numbers rather than FRv1.
84
85 In terms of EFR or MR122 encoder and decoder CPU cycle demand, libtwamr is
86 currently the worst performer; the first version of libgsmefr exhibited the
87 same poor performance. The current version of libgsmefr exhibits somewhat
88 better performance because most saturation arithmetic "basic ops" have been
89 inlined (eliminating the use of a function call for every elementary operation),
90 and the implementation code of those newly-inlined functions has been
91 streamlined for performance, as much as possible with immediately obvious
92 programming methods. The result is about 2x improvement over the original -
93 but sadly, still significantly slower than libopencore-amrnb on the same
94 machine with the same 32-bit execution mode and ABI.
95
96 Given that we (Themyscira Wireless) have a ton of other work tasks in our queue
97 besides the present problem of performance-optimizing libgsmefr to match
98 opencore-amr, this problem is currently shelved. We are releasing our libraries
99 as they currently stand, with the ~2x improvement in libgsmefr over the original
100 but still not matching opencore-amr, and leaving the problem of further
101 performance improvement to be addressed later, after other work of higher
102 priority.