similar to: Re: Speex-dev Digest, Vol 33, Issue 9

Hi All, I am trying to cross compile speex-1.1.12 to powerpc-405, i get a error after the make, speexec.lo error, please help me how to get rid of this error. On 2/9/07, speex-dev-request@xiph.org <speex-dev-request@xiph.org> wrote: > Send Speex-dev mailing list submissions to > speex-dev@xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit >

hello guys this is my code for the C# wrapper. ================================= using System; using System.Runtime.InteropServices; using System.IO; namespace Speex { ///<summary> ///the following class is the win32 SPEEX API that retrieve ///methods and structures from the libspeex file ///</summary> public unsafe class Speex_win32 { #region Speex Constants //global speex

Hi All, I am getting this error during make. please help me./ speexec.c: In function `speex_ec_process': speexec.c:112: syntax error before "noise" cc1: warnings being treated as errors speexec.c:133: warning: implicit declaration of function `speex_echo_state_reset' speexec.c:148: warning: passing arg 5 of `speex_echo_cancel' makes pointer from integer without a cast

I understand that the capture/playback signals need to be sync'd for an AEC to adapt. I'm a little bit confused on the requirements of synchronous sampling between the near end (mic/speaker) and the far end (phone line). I have an embedded DSP system with mic and speaker getting 1msec packets containing 8 samples. We can watch the DSP and ISDN clock frames drift and every few minutes we

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

Jerry, I think that just removing the FIXED_POINT define should be sufficient, though you mind want to turn off MANUAL_ALLOC, because I am not sure if the memory usage is identical for the fixed point build, and the constants in config.h are set for the fixed point build. Are you testing on the simulator, or on an eval board? It does not look like the 6713 has enough memory to hold Speex

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?

I am trying to implement a relatively high number of encoders (24/32) on a single DSP and would like to minimize the memory requirements. Has anyone optimized the persistent EncState memory allocation for multiple channels. The default C64x fixed point implementation allocates 5280 bytes of persistent memory per encoder. I'm willing to restrict my settings to complexity 1, quality 3. It

Hi, Basically, inner_prod() can and should be adapted to the architecture it will run on. It is not really sensitive to noise, so it's possible to tweak it a lot. Also, in the current code, I saturate it to +-16384, which is OK to prevent overflows. I'm not concerned with the case of a constant -16384 value because it can't really happen in practice (especially after filtering). BTW,

I am overriding the inner product routine in ltp.c. To test my replacement, I threw some test vectors at it. I understand the loss of resolution caused by the shift. I also see a FIXED_POINT danger with the summation of four mults overflowing the 32 bit before the shift. I can fix this by accumulating each term into a long, but if the code scales the x[],y[] vectors to avoid this problem I

Ok, I hadn't verified inner product was called with values scaled to <= +-16384. That would make it safe to do a 32 bit add of the intermediate terms. I have implemented the 40-bit accumulator. > by the shift. I also see a FIXED_POINT danger with the summation of four > mults overflowing the 32 bit before the shift. > > I can fix this by accumulating each term into a long,

Hi Jerry, I'd say the best would be to simply replace the #ifdef USE_SMALLFT by #ifdef USE_TI_FFT #include "ti_fft_wrapper.h" #elif defined(USE_SMALLFT) and have everything in the include file. There's no real point in overriding individual functions since they all go together. Also, make sure you wrap the FFT in the same way as I did with the fixed-point kissfft. For example,

Jerry, Thanks for the response; basically, I need to get just the narrow band working now (maybe use advanced features such as jitter buffer, echo cancellation, VAD, etc in the future); the DSP will do the encode and decode simultaneously as data are available. My main objective is just do a voice application that runs on the ARM side of the DaVinci with the codec running on the DSP side; the

Jean-Marc, >> >I fixed it in svn. Could you check that? >> >> Now all platforms match again. Note that the measured SNR for this test >> sample is lower than with the broken code (10.87 vs 11.10), but of course >> this is no way to judge the real quality. > > SNR, especially on a single sample, can be very misleading. Yet, could > you just check that the

Andy Ngo wrote: > Thanks Jean-Marc. Is there a Speex trunk for the C64xx I can use? Or > do I have to figure what options > to turn on (in configure) when building the library? Thanks. Support is in the main version. Just look at the TI/ directory for extra TI-related stuff. Jean-Marc > Regards, > Andy Ngo > > ----- Original Message ---- > From: Jean-Marc Valin

Thanks Jean-Marc. Is there a Speex trunk for the C64xx I can use? Or do I have to figure what options to turn on (in configure) when building the library? Thanks. Regards, Andy Ngo ----- Original Message ---- From: Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> To: ndno72-speex@yahoo.com Cc: jtrantow@ieee.org; speex-dev@xiph.org Sent: Tuesday, December 5, 2006 2:52:02 PM Subject:

First, let me say that I think the speex code is incredible in the way it supports floating and fixed point code from one set of code. The same is true for supporting multiple processors, etc... I've used speex with the PC, TI 64xx and 55xx. Please view the following comments not as an attack on speex (which I think is incredible!) but as my contribution to an open source project. I know

Dear all, I need help with EM algorithm. I am modeling this alogirthm based on " Incomplete Data in Generalized Linear Models" by Joseph G Ibrahim. i have half way through developing the R code based on this this paper, I need little help in tweaking my code furthure. ----------------------------------------------------------------------------

_WIN32 is always defined by the compiler automatically when targeting that platform, while WIN32 only is defined automatically in some configurations, and e.g. in MSVC only ever is defined in project files (if at all). Some other checks in the codebase already check for both WIN32 and _WIN32; those are left untouched. --- include/speex/speex.h | 2 +- libspeex/stack_alloc.h | 2 +-

> That's possible. In any case, u-law conversion can be done with far less > than 1 MHz... About Speex, you would likely need to enable ARM > optimizations and set the complexity to 1 (default it 2). done with arm optimizations and i was still getting high load ... guess it's from gstreamer somewhere. I'll check that next week. thanks, - Christophe