similar to: encoding time

Jean-Marc, Attached is a patch (to build 14264) to fix the TI DSP builds with the recent restructuring of libspeex. The change adds a hook in os_support.h to allow the user to override some memory allocation and I/O functions. A similar hook was present in misc.c, but was lost when that file was removed. Also, the size of the private memory allocation area has been reduced, to match

Hi, I would like to compile the Speex fixed-point, WB decoder for an AT91SAM7S256 ARM7 microcontroller using gcc-arm-elf and was wondering, before I roll up my sleeves and try to figure out all the autoconf things that I'm really unfamiliar with, if anyone else has done this and can share their experiences. I see in the archives that some folk have compiled for this processor before but

On Mon, 21 Dec 2009 21:00:01 +0100, <speex-dev-request at xiph.org> wrote: > Thank you for your product Speex. We want to use it in > microcontroller AT91SAM7S256 (48 MHz). I'd strongly advice to use a higher performance micro. Let's consider that you'd succeed in getting it working right after optimizations. The time you want to add other speex features or other

Hi, I've been trying to get Speex to compile and run on the DSP of TI's new DaVinci System-On-Chip processor, which has both an ARM (ARM926) and a DSP (C64+, based on the C6400). I used the latest code (1.2beta) and followed the example in the speex- 1.2beta1/ti/speex_C64_test trunk to build the Speex library for the DSP. Basically I have a loopback application on the ARM that samples

Hi Jean-Marc, I have tested Speex in fixed-point mode on my PC without clicking noise. As I mentioned below, I tested Speex in fixed-point mode running natively on the ARM side of the DaVinci without click noise. I only get the clicking noise when running Speex on the DSP side. For the TI C64+ DSP on the DaVinci processor, the TI-specific switches doesn't do much other than defining the

Hi Tom Thanks, just at the feasibility phase right now, so this sort of info is really useful. Memory/MHz values for the Tremor/Vorbis code seem to vary wildly - at least I could not find a consistent set of numbers after trawling through the discussion groups... Thanks John -----Original Message----- From: tom abcd [mailto:tom.abcd@gmail.com] Sent: 28 March 2006 16:34 To: Anderton, John

Stripping out usused stuff is very easy, especially with static libraries. The only thing that could cause problem is the speed of the CPU. It's very hard to say what the requirements are because it depends a lot on the exact CPU you're using and (for ARM) the configuration of the cache and the speed of the bus. Jean-Marc Dennis Greenwood a ?crit : > Hi, > > I would like to

Hi, I am currently encoding 32 Khz/Qual-10/UWB encode mode, with MANUAL_ALLOC enabled ( similar to the c5x/c6x configuration). In file sb_celp.c, I noticed the scratch memory grow during recursive (UWB -> WB) calls to 'sb_encode'. 1. 'stack' was not tracked (with 'tmp_stack' as done at other palaces) after/before - auto-correlation/Levinson-Durbin scope (~line

Hi all I'm looking in to using speex for an ARM7 based speech decode development (note we need the decode only). My hope is that we should be able to run the decoder (in wideband mode) real time on the ARM7 (40MHz) without any problems (the difficulty would be in the encode - but we plan to run that offline on a PC - so we should be OK). Can anyone confirm that this is the case please? Also

Hi, I am using speex 1.2beta2 on a C5416, 16 bit, narrowband. The project I am implementing speex into is very limited in Data space. In the speex decode_init and encode_init there are allocs that, combined, take up 0x0F94 of data memory. I do not know why the various allocs are sized the way they are but that number is too big to fit into our project. I was wondering if those numbers (for

Hi, I'm evaluating the libspeex library for usage in an embedded platform based on an ARM7 TDMI micro (the ubiquitous Atmel AT91SAM7S). In details, I'm trying to use libspeex to encode the audio stream coming into the micro from an I2S channel and saving the encoded audio to an SD card (currently in binary format just to test it decoded back to the I2S channel from the saved file), but

I started my project using the CodeComposerStudio speex_C64_test.pjt in speex 1.1.11.1. To build using floating point, I created a new project with the same files and modified ti\config.h to #undef FIXED_POINT. Is there a better way to configure a floating point processor? I have a few TI specific optimizations that could go into the next release. What's the procedure for submitting code?

The majority of a Speex encoder app does fit in a 6713. The 6713 has 8K of L1 and another 256K of memory 64K of which can be configured as L2 cache. (16,32,48, or 64K). One level of TI's website seems to incorrectly indicate only 64K of L2. I turned off MANUAL_ALLOC and have it allocating internal memory using calloc(). I did change the L2 cache to 2 way (32K) and adjusted the heap size to

Sorry everyone, but I figured it out; it's working now. The problem was in my monoToStereo and stereoToMono functions (the Linux OSS driver on the ARM side only supports stereo so I had to convert it to mono before feeding it to Speex); also I had an alignment issue with my buffers I was using on the DSP side. Thanks Jim/Jean-Marc for your help! Regards, Andy ----- Original Message ----

> I followed your advice on running the trivial case. The float version > started cancelling sounds out within a second. The fixed point > version also worked, but took a little longer before the effect was > noticeable. Since I now realized the fixed point version might need a > little more tweaking than the float version, I started modifying some > things and ended up with the

Itay, >I am trying these things, but the main problem that has been bothering >me recently is that the fixed-point algorithm works "sometimes". Meaning >that sometimes it will work well, and other times it will not work at >all. > >I think I've found the source of the problem. The speex_alloc() >function, called by speex_echo_state_init(), calls calloc() and

-----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Thursday, June 14, 2007 11:17 PM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain Michael Shatz a ?crit : >>> Actually, you're the first I know using the VisualDSP++ toolchain >>> :-) >> >> I guess

Hi ! Can anybody point me how to compile speex for subj ? May be I'm doing something stupid.. I just took all files from /libspeex and added them to my project in Code Composer 2.1. Then I set global definitions CONFIG_TI_C55X, FIXED_POINT, DISABLE_WIDEBAND, RELEASE for entire project and edit arch.h and create speex_config_types.h. Then tried to compile it and run. Code seems to be hang in

> -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Thursday, December 14, 2006 2:51 AM > To: Miles, Stewart > Cc: speex-dev@xiph.org > Subject: Re: [Speex-dev] Would be nice to conditionally > compile out coding modes and code tables... > > Miles, Stewart a ?crit : > > I'm only using the narrow-band encoder

Hi, Sorry if this a repost but I want to create the smallest Speex library possible to be put in TI's TMS320 DSP. I'm only interested in one configuration: 5.97 Kbps narrowband. What part of source code can I remove? Currently, when I compiled the version 1.1.12 libspeex.a library with the TI TMS320 and Fixed-Integer options, I get around 522Kb. I would like to reduce it to as small