14 Apr
2009
14 Apr
'09
4:54 p.m.
do we need a switch to select between mISDN bit order and other e1 drivers? what other e1
drivers are/will be supported? or can i just change the bit order, because no other e1
driver is used with the code? if not, i would suggest to add a "msb" flag to the
time slot structure.
i was thinking of having a flag for using hardware multiplexing on hfc-e1 controller, but
because the data is not synchronized (hdlc frames), we need to touch every bit to see
where the frame starts and where it ends, so we have no speed benefit.
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?
-----Ursprüngliche Nachricht-----
Von: Dieter Spaar [mailto:spaar@mirider.augusta.de]
Gesendet: Dienstag, 14. April 2009 16:26
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: success
Hello Andreas,
On Tue, 14 Apr 2009 13:10:36 +0200, "Andreas.Eversberg"
<Andreas.Eversberg(a)versatel.de> wrote:
on the easterhegg 2009 we got everything running. even audio worked! and
we catched our first imsi from a public network.
Congratulation, great to hear that !
@harald | @dieter: other isdn drivers (windows) have
obviously reversed
bit order on transparent channel. bit 0 is exchanged with bit 7 and so
on. to make it work, i did not change the bit order, i just changed the
location of the subslot, and it worked.
I noticed the same with my own Windows driver (its not an official driver,
just my personal very experimental stuff for the HFC-E1 card). However
because it worked with the Linux version (at least on Haralds PC) I though
it was a problem with my implementation and did not take care.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
15 Apr
15 Apr
11:25 p.m.
New subject: success
Hi Andreas,
On Tue, Apr 14, 2009 at 04:54:40PM +0200, Andreas.Eversberg wrote:
do we need a switch to select between mISDN bit order
and other e1 drivers?
what other e1 drivers are/will be supported? or can i just change the bit
order, because no other e1 driver is used with the code? if not, i would
suggest to add a "msb" flag to the time slot structure.
So far nobody has posted any such driver. I've heard there was a Sagoma
port once, and I've heard of Dieters Windows port. But without code, it's
hard to judge. As of now, I would rather keep it simple, e.g. make it work
with whatever code we have in the current tree. If we later get a driver
with different requirements, we alter/adapt the API to accomodate the driver.
i was thinking of having a flag for using hardware
multiplexing on hfc-e1
controller, but because the data is not synchronized (hdlc frames), we need
to touch every bit to see where the frame starts and where it ends, so we
have no speed benefit.
yes, it doesn't make sense, that's what I concluded, too.
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.
Why do you want to do it in kernel space? The data rates are not all that
big. I mean, we are doing multiple gigabit of ethernet traffic to userspace
on mordern hardware - we will probably be able to do kernel/userspace copies
of a couple of kilobits or megabits of GSM traffic. Even if the copying is a
problem, one could work with some kind of zerocopy API with shared memory
buffers.
If you're only worried about latency, then all the various realtime related
bits in the kernel should be sufficient by now for this. If stuff like
pulseaudio can happily live in userspace and achieve low latencies, why should
at phone transcoding software be moved into the kernel?
And the actual CPU consumption for the codec processing will not differ whether
you consume the cycles in kernel or userspace.
Regards,
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
16 Apr
16 Apr
12:08 a.m.
New subject: success
-----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-----
5915
days inactive
5916
days old
2 comments
3 participants
participants (3)
-
Andreas.Eversberg -
David A. Burgess -
Harald Welte