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)