similar to: Operation with continuous tone

Hi Jean-Marc, yes, problem exists in narrowband-mode, too. I already twiddled with max_gain, but did not have real success. I changed line 337 of ltp.c (function pitch_gain_search_3tap_vq) if (sum>best_sum && gain_sum<=max_gain) { to if (sum>best_sum && gain_sum<max_gain) { -- that stabilizes speex for 2000 Hz and 2200 Hz input on quality setting 7 (23800

Jean-Marc, I have traced the second infinite loop further. When st->adapted becomes true (mdf.c line 623), the first Yf[i] value is 4, the leak_estimate is 0xd4e, the resulting r is 3. The first value in st->Rf is 0, so e is 1, and r is set to e>>1, or 0. A little later there is a divide by r, and there is the hang. It seems that the 0 in Rf[0] is the problem, but I am not

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

Hi again, I tested lower cumul_gain limit values. In fact, I reduced the value to 240000, 230000, 220000, ..., 20000, 10000, 5000, 2000, 1000, 500. (quality 7, complexity 2) For input signal 2000 Hz, the values 190000, 130000, 60000, and 1000 look o.k., all others don't. For 500, the (zoomed out) waveform shows some kind of amplitude ripple -- i think, this value is definetely too low. I

> I built and ran the same test on the TI C64 simulator, and the echo was > canceled nicely (about 10:1 reduction in the peak amplitude during the > second of two brief speech bursts). So, my problem must again be related to > the 16-bit processing on the C5X DSPs. Good. At least we've narrowed it down a bit. > Also, the line where it is hanging is: >

Hi, So I see in: split_cb_shape_sign_unquant this call is going wrong: ind[i] = speex_bits_unpack_unsigned(bits, params->shape_bits); ind as a way negative number- basically this should return bet. 0-255 or somesuch right? So seems like I need to reset speex at this point if if (ind[i] > 256) like the note says. So I guess my question is is this range still valid? also what is the

The builds that I referred to in my last mail should be 11398 and 11387, not 11387 and 11343. Sorry for any confusion. - Jim ----- Original Message ----- From: "Jim Crichton" <jim.crichton@comcast.net> To: "Jean-Marc Valin" <Jean-Marc.Valin@USherbrooke.ca> Cc: <speex-dev@xiph.org> Sent: Wednesday, May 10, 2006 11:47 AM Subject: Re: [Speex-dev] Speex echo

> The C55 and C64 builds diverge in exactly the same place as before (byte > 0x1000). The output from C55 build 11387 (svn head) diverges from C55 build > 11343 slightly later (byte 0x1116). Similarly, the output from C64 build > 11387 (svn head) diverges from C64 build 11343 slightly later (byte 0x1126). > So, your change clearly had an effect, not just on the 16-bit machine,

Hi Jean-Marc, do you have any other ideas what to look for? Or do you currently debug yourself? As I already wrote, I'm out of ideas... best regards, Frank Frank Lorenz <Frank_wtal at web.de> hat am 18. Januar 2010 um 16:39 geschrieben: > Yes, I did. > > As mentioned earlier, only the enhancer inside the docoder produces a lot of overflow messages (it points to lines 68

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

>> My builds for the two platforms used exactly the same source files, >> though >> there were a few ifdefs in the test_echo routine to deal with file I/O >> for >> the C55 with its 16-bit char size. When I get a chance, I will add some >> instrumentation and see if I can find where things diverge. Just looking >> at >> the canceled audio files

Hi , We would like to know as to what is the impairment caused by the Speex codec I mean what is the value of equipment impairment factor Ie ( as defined in G.107 Emodel Standardization ) for speex codec ? The standard G.107 does not talk about the Ie values of this codec type. Would greatly help if I could get to know the same, Awaiting your response, thanks supriya -------------- next

Jean Marc, >> 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

> 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

Hi Jim, Thanks a lot for investigating. It definitely makes sense now. I'll fix the problem now. Is there any other place where you see that same (or similar) problem? Jean-Marc Jim Crichton a ?crit : > Jean-Marc, > > I dug into this further, and found that the warning occurred when PSHR32 > had a shift greater than 15. > > in fixed_generic.h, PSHR32 is defined as: >

Just tried your files and I'm not running into any infinite loops and the cancellation works fine. Unless the C6x has the same problem, I suspect a 16-bit problem. I'll check and see if I find something. About the r=0 problem, I can't find where it ends up in a denominator, so I suspect is not (directly) the problem. Jean-Marc Le lundi 08 mai 2006 ? 20:05 -0400, Jim Crichton a ?crit

>> When the dust >> settles, I will send a patch with additions to the TI directory for the >> echo >> canceler example, including instructions on these last changes. Also, I >> would like to modify the memory allocation to follow the same structure >> as >> the encoder/decoder, including the ability to override the malloc >> function. >

Jean-Marc, >> Build 11169 in SVN works correctly. > > Good. I'll try not to forget the EXTEND32 from now on. > >> I have attached a zip file (renamed >> .txt) with a patch to bits.c to make the byteswapping for TI DSPs >> consistent. > > Seems like unzip can't read it. Either it's in an unknown format or the > file got corrupted. Could simply

Jean-Marc, I recently started looking at running the echo canceller on a TI C55 DSP along with the 8kbps narrowband Speex encoder/decoder. This is one of those "braindead compilers" that you refer to from time to time, and cannot handle the float struct assignments in the return statements in pseudofloat.h. Most of these were eliminated in build 11311 (patch by Brian Retford), but

Jean-Marc, Well I finally tracked down the problem. Then I checked my mail and found that you had fixed it several hours earlier. :( Build 11387 produces the same result as my modified build 11343. Because of compiler limitations in the TI tools, I did have to make modifications to pseudofloat.h (separating return of float values) and nb_celp.c (adding braces around a variable declaration