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/.
Harald Welte laforge at gnumonks.orgHi 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 at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090415/766fbac1/attachment.bin>