similar to: Fixed-point update

Just one thing I forgot to say: you need to add -DFIXED_POINT to the compile options. Jean-Marc Le dim 28/09/2003 à 19:30, Jean-Marc Valin a écrit : > 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

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

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:

Hmm, what these instructions do? (I know nothing about ARMs; I have some knowlege about x86 assemblers and programming). Cant we use pure standard C++ or Java? Does Speex work with fixedpoint math? (As far as I know Java on 6600 has no builtin floatingpoint, there is emulation class somewhere on the net, but it is probably painfully slow.) I do not know if this processor has builtin

Hello Greg If money isn't a problem Intel has an optimized compiler for eVC and XScale processors http://www.intel.com/software/products/compilers/techtopics/PCA_Optimization_WP.pdf If you have any luck getting the eVC compiler closer to realtime I'd really like to know. I'm still far from realtime when using Speex 1.1.3 on a HP iPAQ (Intel pxa255). Best regards Bjoern D.

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

Hi, I encoded file in a ipaq 1940, pocket pc 2003, processor Samsung s3c241(similar to ARM), 266 Mhz. I would like to know your opinion for the quality output if this is right to entered parameters. File original: http://padawan.ing.puc.cl/chavezorig.wav File encoded: http://padawan.ing.puc.cl/chavezq1.wav The parameters for encoded are: state = speex_encoder_init(&speex_nb_mode); int tmp=0;

Thanks very much. You mean both encode and decode simulateusly (duplex)? Could you test the Java version (jspeex) on that iPaq too? (I do not have anything other than very fast PC, so I cant do this...) And, in phone, the mic can record not only the users speech but also voice from the other side (from speaker)... Does this make compression harder or the result worse? How can this impact

Hi all, I'm quite new to Speex and i'm tryng to do a porting of it for my pocketpc platform.... The encodig time seem to be too hight, i think something goes wrong putting --enable-fixed-point --enable-fixed-point-debug --enable-arm-asm in project setting of EVC++ 3.0 (i've got EVC++ 4.0 too) i do my test with an Ipaq 3850 (206 MHz Intel® Strong ARM 32-bit RISC Processor) running

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

Target is Spv & Nokia phones ARM and also ipaq ARM. With the generic fixed point at complexity 0 I am still about 1.6x realtime for narrowband. The MS eVC compiler does not support inline assembler, only separate assembler functions. Does anyone have a feeling on whether a 2x speedup is possible if I hand tune a few functions? -greg. --- >8 ---- List archives:

Hi, just to let you know that unstable version 1.1.1 is out. It includes the latest fixed-point changes which can be enabled with --enable-fixed-point (as configure option) or -DENABLE_FIXED_POINT (for win32). The port is not complete, but most of the floating-point operations have been converted. Please give it a try and report any difference with previous versions (both for float and

Le dim 09/11/2003 à 14:33, Steve Kann a écrit : > Just out of curiosity, has anyone profiled the difference between the > floating point and fixed point implementations on processors with > decent floating point support? (i.e. x86, PPC). On recent x86 processors, floating point is faster than fixed-point. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS

> Yes, i have been using speex in my VoIP gateway product. There are > hundreds of threads that simultaneously call various speex APIs and > execute without any problem. But ofcourse, I use a speex encoder/decoder > vars on per stream basis. Its been tested successfully on Linux/Win2k. Actually, I just realized I fixed a potential minor thread problem recently. It's in 1.1.1

> Am I right with the assumption, that currently you have to enable > processor specific optimizations with compile/configure options? > > How difficult would it be to add support for runtime CPU detection? > Is this a feature you might consider adding? Pretty complicated because of some annoying decisions taken by the gcc team. The problem is that gcc won't let you use

Le jeu 15/01/2004 à 15:30, Daniel Vogel a écrit : > Unrelated, but please use SSE/MMX/... intrinsics on Windows instead of using > inline assembly so you also get the speed benefit on Win64. OK, so here's a first start. I've translated to intrinsics the asm I sent 1-2 days ago. The result is about 5% slower than the pure asm approach, so it's not too bad (SSE asm is 2x faster

> > OK, so here's a first start. I've translated to intrinsics the asm I > > sent 1-2 days ago. The result is about 5% slower than the pure asm > > approach, so it's not too bad (SSE asm is 2x faster than x87). Note that > > unlike the previous version which had a kludge to work with order 8 > > (required for wideband), this version only works with order

Hi everyone, I've just released version 1.1.4. This includes some code cleanup and improvements to the fixed-point port and SSE optimizations. All the SSE code has been converted to intrinsics and some new functions have been implemented with SSE. Overall, the speed has been increased by up to ~30% with SSE. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS

> I had a similar question ... is the endian-ness of the encoded > speex file, system dependent? or is it always little endian? If it's > always little endian (like the header seems to be) then big endian > machines (or java) will need to map everything to bigendian before > decoding ... Well, wav's are considered little endian but for raw files, there's a

> Personally, I don't think much of PNI. The complex arithmetic stuff they > added sets you up for a lot of permute overhead that is inefficient -- > especially on a processor that is already weak on permute. In my opinion, Actually, the new instructions make it possible to do complex multiplies without the need to permute and separate the add and subtract. The really useful