This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
David A. Burgess dburgess at jcis.net-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The GSM codecs are: 06.10 full rate (FR). Well known source code "toast" available from TU -Berlin. Patents held by Phillips but rarely enforced. This is the GSM codec use in Asterisk. Sound quality is generally considered good but not great. 06.20 half rate (HR). Source code in C available from ETSI as specification 06.06. I don't know the patent status but would guess it's that same a 06.10. Sound quality is OK if you only transcode it once, but not considered acceptable for mobile-to-mobile calls. 06.60 enhanced full rate (EFR). Source code in Cavailable from ETSI as specification 06.53. Patents, I believe, held by Nokia and definitely enforced. Probably the most widely used codec today. 06.90 adaptive multirate (ARM). Can run on full- or half-rate channels. Source code in C available from ETSI as specification 06.73. I don't recall who holds the patents, but I know they are enforced. Carriers love it because it can give acceptable quality on mobile-to-mobile calls on half-rate channels. The C code is not efficient in these ETSI reference implementations, but if you actually read it you can see how to speed it up by rewriting the arithmetic macros. All arithmetic is 16-bit integer. NONE of this ETSI reference code includes the forward error correction (convolutional coding and parity). It's not hard for FR, HR and EFR but hideously complex for AMR because of its variable-rate turbo-coding. All of the math for this is described in GSM 05.03, but you need to understand the Viterbi algorithm to code it. All GSM codecs have an inherent latency of 20 ms and are computationally "light" on current-generation machines. There's not much point trying to shove them into the kernel for performance. And from an architecture standpoint, I don't think it's a very clean thing to do. [Disclaimer: This is information about the GSM specifications themselves and codecs used in GSM handsets, not technical information about a BTS design.] - -- David On Apr 15, 2009, at 2:25 PM, Harald Welte wrote: > >> to make a better processing in kernel space, i need to put the gsm >> speech >> codec into kernel space. i need a source code that is open, light >> weight, and >> without integer math. any suggestions? > > I am still doubtful about this. There are FR, EFR and AMR codecs, > and all or > at least most come in full-rate and half-rate flavours. They are > heavily > patent encumbered, so merging them in mainline Linux is unlikely to > happen. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknmWuQACgkQ8seXSYwY0sgjfwCgyDRp+djv0jSZjaSOY8fIeV7z n4UAoMQ0gPO6OZ5XotMC9PXa2cMSILrY =vY3w -----END PGP SIGNATURE-----