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(a)gmail.com>

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=cfaec3a2f6590bafcae… 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: 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: 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 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'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. -- - 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)

On 05/23/2011 11:55 AM, suraev(a)stud.ntnu.no wrote: 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: 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 :/ 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. 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. 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. TBH, I do not want to be that maintainer; but my work should be easy to grab and maintain. There is emdebian, but as mentioned, it is (was?) not fully functional on the target side of things. Isn't this managed by the code upstream, rather than packaging? Isn't the library automatically included in the final applicative images? (I haven't had a look at the project for a while, sorry) hackable:1 can do that too. :) HTH, -- khorben