16 Apr
2009
16 Apr
'09
12:08 a.m.
-----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-----