similar to: Re: os_support.h, libc overrides

Jean-Marc, > That reminds me that I've just moved lots of stuff around with the > allocation functions. Can you check that the TI stuff still works with > that? In the end, it'll probably make things easier for you now. For > example, if you link statically, wideband should be automatically left > out if unused. Also, all the libc stuff is now in os_support.h, which is >

Please correct me if I am wrong, Jean-Marc, but I do not think that any patches are getting applied to 1.0.5 anyway. Also, if you expect a patch to be applied, you will need to provide the changes as a patch, not as a modified copy of the source tree. The 1.2 branch includes a mechanism for private memory allocation from a static buffer. You provide a usermisc.h file that replaces 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

Hi Jean-Marc, Jim, Saad has been keeping me in the loop on your recent discussions. Since all of our testing has been against 1.0.5, based on that being the last non-beta version, that's the particular scope of the task that Saad is working on right now. I like what I'm reading about as far as encoder/decoder quality improvements e.g. in the 1.2 betas, and am going to push for

> 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

Good afternoon! Thank you for your product Speex. We want to use it in microcontroller AT91SAM7S256 (48 MHz). We applied the following: #define FIXED_POINT #define DISABLE_WIDEBAND #define DISABLE_HIGHPASS #define MANUAL_ALLOC #define OS_SUPPORT_CUSTOM at speex_encoder_init(&speex_nb_mode); speex_decoder_init(&speex_nb_mode); tmp=2; speex_encoder_ctl(st, SPEEX_SET_QUALITY,

Jim, You're right, the memset really is there, how could I miss that? :) I also spoke too soon, as my change doesn't solve anything. At each run, something random causes the algorithm to either work or not work at all. There is a correspondence between whether the echo cancel works and whether the st->PHI and st->W arrays contain data or zeroes. (the arrays contain zeroes when alg

Hi, Just a couple tips to reduce complexity. First, I think you'd get a good speedup by enabling the PRECISION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already

I am having trouble understanding the stack allocation scheme when using a C55xx device. From what I can tell, the GLOBAL_STACK_SIZE is set in arch.h to 100,000 bytes (when using FIXED_POINT), which is then used in the ALLOC_STACK macro found in stack_alloc.h. This macro seems to say, if global_stack==0, then call celt_alloc_scratch, found in os_support.h, which in turn attempts to allocate (using

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

Jim Crichton, I'm trying to run speex on omap 1610 platform and i saw that you have a patch for c55. When i saw your mail about this, i decided to ask you for send me those files above: include\config.h (not automatically generated, sets memory sizes, enables manual alloc) include\speex\speex_config_types.h (match Speex types to compiler types, not generated from types.in

Joost Schuur wrote: > Saad has been keeping me in the loop on your recent discussions. > Since all of our testing has been against 1.0.5, based on that being the > last non-beta version, that's the particular scope of the task that Saad > is working on right now. I'm just saying it's useless to do any work on 1.0.5. It is inferior to the latest beta in all aspects,

Jean-Marc, I have attached a small patch with modifications to arch.h, bits.c, and misc.c. This contains the few mods remaining to support the various fixed point TI DSPs after the work that you did at the end of May (thank you for this). arch.h: Add switch for compilers not supporting "long long" (C55x does, C54x and older C64x does not) bits.c: Allow external definition for max

Hi Jim, Jim Crichton wrote: > Please correct me if I am wrong, Jean-Marc, but I do not think that > any patches are getting applied to 1.0.5 anyway. Also, if you expect > a patch to be applied, you will need to provide the changes as a > patch, not as a modified copy of the source tree. That's right. I won't be applying anything 1.0.5 unless it's a security issue or

-----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Tuesday, June 19, 2007 6:38 PM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain >> Yes, data footprint in the new version is quite manageable. Still I would >> wish better documentation for speex_alloc_scratch(). >

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 ----

Joost Schuur wrote: > My primary concern is the use of the word 'unstable' on the current > download page for 1.2b2. One of our major devloper partners in > particular saw that reference and opted to use 1.0.5 on their PS3 title, > which is why we based our work for them on 1.0.5. The kind of commercial > game developers that are our customers aren't going to have the

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

Thanks Jim for looking into that, I was really starting to wonder what was going on. Let me know if you find a way to tell the compiler to stop complaining. Jean-Marc Jim Crichton a ?crit : > I looked back at my old C55 EC build, and I had the same warning in > mdf.c which Mike found. The assembly code did have a valid shift, and > this build did cancel echo. > > When I built

Itay, I tested on C6x in May with build 11343 and 11398, and it worked fine. I just ran the same test with build 11768, and there was no cancellation, just as you saw. I will try to track this down in the next day or two. In the meantime, I suggest that you try testing with 11398. - Jim ----- Original Message ----- From: Itay Chamiel To: speex-dev@xiph.org Sent: Monday, August 14,