similar to: fixed point macros

Do the two types have a constant integer and fractional part (ie 8.8 and 16.16), or does it vary. If it varies, is there any way to figure out where the split is for a certain variable? On May 8, 2004, at 11:28 PM, Jean-Marc Valin wrote: > Le sam 08/05/2004 à 19:30, Rib Rdb a écrit : >> is there documentation of what the various fixed point macros do, so I >> can work on

is it safe to compile libspeex with -O3? I've changed all the asm's to asm volatile, but I don't know if there's other problems O3 would cause. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2363 bytes Desc: smime.p7s Url :

I submitted a version of testenc.c to this list MONTHS ago that fixed this problem. It uses a reconfigurable group delay. If you had given me cvs access I could've committed the changes myself. Anyway, the file is attached (again). Maybe this time you'll actually notice the email. Sorry if I seem a little short. It's just very annoying to put the time into learning and improving a

Hi all, I'm new to the group. I'm looking at the speex code with an eye towards maybe helping out with either codec optimization or fixed-point implementation, The SNR calculation in testenc.c and testenc_uwb.c doesn't make sense to me. The code is { float enoise=0, esig=0, snr; for (i=0;i<FRAME_SIZE;i++) {

Hi, I have been doing some work on a fixed-point port and it is now in CVS. All of the CPU-intensive parts should now be using only integer operations. Now, it's in a state where even non-coders can help: find bugs. With all these changes, there are probably several bugs and some may show up only under specific circumstances. Please test to see if the fixed-point behaves the same as the

I have read a few messages about a fixed point version and I have some questions. 1. Will just the decoder be available in a fixed point version. 2. If the encoder is available will it work on a 400 mhz XScale "Strongarm" 3. Will it work on a dsp? if so how fast of one will I need. 4. Any chance of a FPGA version? I really need to be able to encode in real time or very close to it in

Hi, I am trying to get speex_preprocess in real time for Arm. Tried 32.32 fixed point but looks like even that precision is also not enough. Any suggesions? Regards, Phani. ===== !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !The butterfly counts not months but moments,! ! and has time enough. ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Hello, Can somebody tell me something about the status of the fixed point code at this moment ? I did some tests today with the latest CVS version of speex, but enabling -DFIXED_POINT results in distorted sound in my test application. Is the fixed point code supposed to work properly at this moment ? Regards, /Ico -- :wq ^X^Cy^K^X^C^C^C --- >8 ---- List archives:

Le dim 28/09/2003 à 19:30, Jean-Marc Valin a écrit : > > Can anyone with an iPaq (or > > similar hardware) confirm that? The code is available here: > > http://www.speex.org/misc/speex-1.1-int.tar.gz If you still have your Sourceforge account, you can login to the Compile Farm and try to compile Speex on an ARM machine (among others). You can get more information on that at the

I was wondering if the developers were using anything to "objectively" test the quality of the speex vocoder. For instance PSQM or one of the many derivatives. Mean Opinion Scoring seems an expensive route. Is there some open source software to use for this? <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To

Hi there. Just a little status update how that integerization is coming along. I am trying to limit myself to 32 bit arithmetics. That means not using any __int64 or long long datatypes at any point. I have now replaced all steps up to including the estimation of the LPC filter coefficients with integer code. That is about a quarter of the total work completed, I would say. One problem that i

I was also wondering if there is a standard set of input sequences people are using to test Speex. I haven't stumbled upon it/them yet. > -----Original Message----- > From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org]On > Behalf Of Jean-Marc Valin > Sent: Tuesday, February 25, 2003 7:24 PM > To: speex > Subject: Re: [speex-dev] Quality > > > > I

Hi, Now that Speex is getting pretty stable, I have decided to make a fixed-point/integer port the #1 priority. At this point, I'm looking for help from people with prior fixed-point experience and/or a good signal processing background. Anyone would like to volunteer? I have already started the port by converting to int some of the most used functions. While this should only have a small

hello, My project is to implemente an audio compression algorhitm on a DSP TMS320DM642. I think that SPEEX can be a good choice because fixed-point have been developed. I would want to know how I can choose the fixed point in the program I want to know if it is possible to do a real time acquizition and to compresse in real time the audio input signal. By example, I have on my demonstration card

"Do you mean doing that on a DSP, or on a PC (before you do it on DSP)?" Yes I want do that with a PC in order to test if I can encode in real time an external audio source and then I want to implemente SPEEX in a dSP. guillaume Jean-Marc Valin a écrit : > > I want to know if it is possible to do a real time acquizition and to > > compresse in real time the audio input

Jean-Marc Valin wrote: >>Reverberation suppression? >> >> > >Basically, it means that if you are in a room with lots of echo (long >decay), I can reduce it a bit. > > > >>I guess this would help reduce local source echoes? I've never >>_noticed_ that to be a problem in my use, but I would imagine that >>using a notebook's

Hi, I just did some experiments and it seems like the high system CPU time is not due to one specific part of the code, but rather to the extreme inefficiency of float emulation under Linux. I was expecting float emulation to run something like 30 times slower than integer, but it looks like its more like 3000 times slower. This means that all of the float operations must be removed for the code

I'm trying to get these cleaned up and landed, but I'm running into some trouble with this patch. Using commit a08b29d88e3c (July 21) of Ne10, I'm seeing test failures for 60-point FFTs: nfft=60 inverse=0,snr = -3.312408 ** poor snr: -3.312408 ** nfft=60 inverse=1,snr = -16.079597 ** poor snr: -16.079597 ** All other sizes tested appear to work fine (84 to 140 dB of SNR). This

It seems to work ok with the same audible quality as a standard sampling rate. Is there any way to test this? Will superimposing an inverse wave over the origional produce a meaningfull result? Thanks for your time, Ryan de Leeuw <p><p>>Sorry for the delay. I've been doing a couple tests >and what I'd suggest >is encoding using the narrowband (8 kHz normally)

On Mar 28, 2004, at 8:23 PM, Jean-Marc Valin wrote: >> The st->zeta pointer isn't freed in the >> speex_preprocess_state_destroy() >> function of the preprocess.c file (alloced in line 167). It's in >> Speex 1.1.4 >> by the way. > > Oops... Thanks for letting me know. I'll change that for the next > release (in the mean time, the fix is