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@lists.gnumonks.org Betreff: Re: success
Hello Andreas,
On Tue, 14 Apr 2009 13:10:36 +0200, "Andreas.Eversberg" Andreas.Eversberg@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
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,
-----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.
-
Andreas.Eversberg -
David A. Burgess -
Harald Welte