similar to: AEC on a TI C6x - has no effect

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,

For me, this was a memory allocation problem. I am using a private heap, and somewhere between build 11522 and 11700, the allocation for two large buffers was changed from calloc to speex_alloc (I am sure that this was a cleanup change, and I have not had a chance to locate it yet). This was overrunning my heap, and enlarging the heap solved the problem. I suspect that Itay is having a

Itay Chamiel a ?crit : > Hi Jim, > > I've tried both 11343 and 11398 (after fixing a couple of compiler > errors) and annoyingly enough I get the same results as the current > build: float works, fixed doesn't. I also saw the same phenomenon where > the st->W and st->PHI arrays are all zeroes in fixed point mode. > > I'm still optimistic though, as

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

> 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

Jim Crichton a ?crit : > 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. Hmm, that's odd because the fixed-point seems to

Jean-Marc, 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 following changes:

Thanks to a tip from Jean-Marc, I tried the floating point version and it worked well. If anyone has a clue as to why the fixed point version doesn't work, let me know as I would really appreciate the CPU time reduction (20% as opposed to 70%). Thanks, -itay -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

Jean-Marc, 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 returns a zeroed array. On

The attached file contains build files for TI's Code Composer Studio (CCS) for the C54x, C55x, and C6x DSPs. I had intended to post this a couple of months ago, but it took a long time to get around to doing the little bit of cleanup required. This is a file I/O loopback application suitable for running with the CCS simulators, for evaluating memory and MIPs requirements for these

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: maleout12may.wav Type: audio/wav Size: 95884 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20050524/57112d0c/maleout12may-0001.bin

> Nice call. The culprit is SHRL32. This is not used in many places, and in > most of those, the operand comes from EXTEND32. The only really suspicious > instances is in lsp.c (lsp_interpolate): > > spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); > (subframe is an int) > ... > I see that your changes include adding an EXTEND32 to the line above.

> For the persistent storage, the only change that I have made is to > MAX_CHARS_PER_FRAME, which is set to 2000 in bits.c. I changed bits.c to > set this value only if it was not already defined, and then put my own, much > smaller value in config.h. Yeah, I think I'll add an option like that. > For the scratch stack, I replace the fixed values in nb_encoder_init and

> I incorporated Stuarts fixed_c55x.h file, and that eliminated the artifacts, > at the expense of a ~30% increase in MIPs. Now the male.wav file through > encoder/decoder produces a bit-exact match with the C64x test that I did > earlier. I will do some more testing to isolate the, but it may be a few > days before I get to this task. As Jean-Marc says, fixed_generic should

>> Nice call. The culprit is SHRL32. This is not used in many places, and >> in >> most of those, the operand comes from EXTEND32. The only really >> suspicious >> instances is in lsp.c (lsp_interpolate): >> >> spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); >> (subframe is an int) >> ... >> I see that your

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

Hi Jim, Thank for the patch. I'll apply it when I have a few minutes. If I haven't done so after a few weeks, please send it again. I'm in the process of relocating to Australia, so everything's a bit of a mess around here. Also, please post the c5X-specific files to the list (.cmd, .pjt, ...) so they'll be archived. Last thing, I see you defined spx_word64_t as long long for

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

> The C5x and C6x output diverges in build 10143, which has log message "lpc > floor converted to fixed-point." Also, the measured SNR changed from 11.05 > in builds 9854-10141 to 9.22 and 9.24 in 10143. Actually, build 10143 introduced another bug, that was the reason for the 1.1.11.1 release. > There is just four lines in modes.c which declare the constant, and one