hi Sylvain Thank you!

where i can find some doc about the internal, undocumented, calypso buffer format? I want to join bb project. Hope me can do some work.

I am linux bsp engineer.

Regards Shrek W

2011/2/22 Sylvain Munaut 246tnt@gmail.com

Hi,

...

About voice，I have one question. In the latest git code, when I use bb to call other phone, it will

product a

...

file voice.raw.

How I can play the voice.raw? which kind of format? 16bit or 8 bit pcm?16khz and 8khz?LSE or MSE? In fact i used the cooledit to play it, both 16khz and 8khz, it has only noise.

It's the internal, undocumented, calypso buffer format.

I have the format details somewhere but not near me ... I (or most likey Jolly) will write a converter soon, it's work in progress.

...

Other question, I want to input voice from pc that run BB, then the voice can be sent by C123. But I found the voice that be sent by C123 is C123 input voice. Can we realize the idea?

again, WIP ... just wait.

Cheers,

Sylvain

where i can find some doc about the internal, undocumented, calypso buffer format?

As pointed out, there is no documentation.

I don't remember exactly how I learned what the format was ... (probably trial and error, possibly a few hints from the DSP code ...)

I've just pushed support for the FR codec buffer format in gapk (thanks to steve-m for the sample file btw). http://git.osmocom.org/gitweb?p=gapk.git;a=commitdiff;h=cfaec3a2f6590bafcaec...

I'll do EFR and HR format whenever I get sample files (but I'm away from my hw right now).

Cheers,

Sylvain

I am trying to convert the voice.raw file generated by the mobile application ion the Sylvain's test branch to audible audio using the GAPK tool. I seem not to be able to run in with the apropriate parameters as I only get screeching sounds as a result. I assume the the raw TI calypso audio is in the format indicated with ti-fr. I tried things as: gapk -i voice.raw -i voice.pcm -f ti-fr -g rawpcm-s16le

but with no usefull result. Could anyone give me some guidance?

regards, Stefan

----------------------- this is the output of the GAPK tool as I compiled it with the supported codecs. Is there anything missing?

Usage: /home/gsm/project/gsm/gapk/src/.libs/lt-gapk [options]

Options: -i, --input-file=FILE Input file -o, --output-file=FILE Output file -f, --input-format=FMT Input format (see below) -g, --output-format=FMT Output format (see below)

Supported codecs: name fmt enc dec description pcm * Raw PCM signed 16 bits samples hr * * * GSM 06.20 Half Rate codec fr * GSM 06.10 Full Rate codec (classic gsm codec) efr * GSM 06.60 Enhanced Full Rate codec

Supported formats: amr-efr Classic .amr file containing EFR (=AMR 12.2k) data gsm Classic .gsm file format hr-ref-dec 3GPP HR Reference decoder code parameters file format hr-ref-enc 3GPP HR Reference encoder code parameters file format racal-hr Racal HR TCH/H recording racal-fr Racal FR TCH/F recording racal-efr Racal EFR TCH/F recording rawpcm-s16le Raw PCM samples Signed 16 bits little endian ti-hr Texas Instrument HR TCH/H buffer format ti-fr Texas Instrument FR TCH/F buffer format ti-efr Texas Instrument EFR TCH/F buffer format

On 05/17/2011 05:27 AM, Pedro Collado wrote:

like openbts

sure. Would you want to create the scripts for that?

holger

Hi Lokkju and others,

On Mon, May 23, 2011 at 12:56:38AM -0700, Lokkju Brennr wrote:

If we just create a Debian dpkg that packages all the osmocom functionality, it'd be really easy to pull off with Debian Live.

That is not that easy. You will first need to package a cross-toolchain, and then include the source code for at least the OsmocomBB firmware. Also, how to cleanly handle the libosmocore cross-compilation in a debian package is probably not that simple.

For OpenBSC, packaging stuff is easy and fine. But OsmocomBB, it is an entirely different story. I think there's no alternative to simply include the git repository and have people compile the specific branches they want, with manual TX enabling, etc.

The other issue with distributing a live CD with lots of exceutable code is of course license compliance. This means at least for all GPL/LGPL/AGPL licensed code, the complete corresponding source code has to be offered and made available.

I will say it would be nice to have a set of reference binaries (both host and target), so you could immediately rule out any build issues when troubleshooting.

I don't think so. Especially for the host, you have so many things that play into the picture (architecture, libraries/versions, host CPU architecture, ...)

I might be interested in building the packaging scripts if no one else is already working on it.

I've recently posted a call for a dpkg package maintainer. This would be a start for libosmocore, openbsc, openggsn, etc.

Next steps would be: * package a suitable cross-toolchain * make osmocom-bb host programs use the libosmocore on the host * create a package for the cross-compiled (target) libosmocore * provide an apt repository of all the packages (and source packages)

Creating the Live CD is the easiest and last step. Please don't start with the last step before the preconditions are met.

On 05/23/2011 11:55 AM, suraev@stud.ntnu.no wrote:

23.05.2011 10:08, Harald Welte пишет:

...

That is not that easy. You will first need to package a cross-toolchain, and then include the source code for at least the OsmocomBB firmware.

Probably this https://launchpad.net/~bdrung/+archive/bsprak could be a good starting point for toolchain packaging.

Yes, either abuse the GNU/Linux ARM toolchain from Embedian (or in Ubuntu the Linaro cross gcc), or we need to package a plain ARM ELF newlib one.

holger

Hi all,

On 23/05/2011 10:08, Harald Welte wrote:

Hi Lokkju and others,

On Mon, May 23, 2011 at 12:56:38AM -0700, Lokkju Brennr wrote:

...

If we just create a Debian dpkg that packages all the osmocom functionality, it'd be really easy to pull off with Debian Live.

some packages are available in the hackable:1 project: http://trac.hackable1.org/ http://build.hackable1.org/debian/dists/wip-oldstable/main/

As the last URL suggests, I haven't updated them for a while though :/

That is not that easy. You will first need to package a cross-toolchain, and then include the source code for at least the OsmocomBB firmware. Also, how to cleanly handle the libosmocore cross-compilation in a debian package is probably not that simple.

It is not easy, but feasible. I have used the toolchain from the Emdebian project, and managed to cross-compile libosmocore.

The GSM applications compiled this way did not fully work though. It would be really nice if OsmocomBB's code could support more toolchains; I'll try to investigate this myself if I can find some time for this.

For OpenBSC, packaging stuff is easy and fine. But OsmocomBB, it is an entirely different story. I think there's no alternative to simply include the git repository and have people compile the specific branches they want, with manual TX enabling, etc.

Right, this is another issue altogether. There also, it would be great if some features could be enabled through command-line arguments, but I also understand why this is not always feasible/desirable even. As for choosing branches, that's going to be the case for pretty much any software package in any distribution, and my preference goes for tracking "stable" code, and therefore track the "master" branch by default.

For the record, my packages were using the master branch indeed, with TX disabled IIRC.

The other issue with distributing a live CD with lots of exceutable code is of course license compliance. This means at least for all GPL/LGPL/AGPL licensed code, the complete corresponding source code has to be offered and made available.

hackable:1 also features a script to generate ready-to-boot images, and could be extended to generate live CDs. Since it is based on Debian and fully open source, GPL compliance should not be an issue.

...

I might be interested in building the packaging scripts if no one else is already working on it.

I've recently posted a call for a dpkg package maintainer. This would be a start for libosmocore, openbsc, openggsn, etc.

TBH, I do not want to be that maintainer; but my work should be easy to grab and maintain.

Next steps would be:

• package a suitable cross-toolchain

There is emdebian, but as mentioned, it is (was?) not fully functional on the target side of things.

• make osmocom-bb host programs use the libosmocore on the host

Isn't this managed by the code upstream, rather than packaging?

• create a package for the cross-compiled (target) libosmocore

Isn't the library automatically included in the final applicative images? (I haven't had a look at the project for a while, sorry)

• provide an apt repository of all the packages (and source packages)

hackable:1 can do that too.

Creating the Live CD is the easiest and last step. Please don't start with the last step before the preconditions are met.

:)

HTH,