similar to: Speex 1.1.4 is out

> 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

> Is it a problem if all the files are compiled with -march=pentium3 > ? The patch that we sent in already detects in the configure.in script > which system you are on and sets a define correctly, i.e. _USE_SSE. Well, if what you want is auto-detection, turning on -march=pentium3 means that the code will crash on anything lower than a pentium3. Not really useful. Of course,

It's not really documented, but when you compile with --enable-sse, you need to add -march=pentium3 to the compile switches. That's actually a gcc requirement. Jean-Marc Le mer 21/01/2004 à 04:22, war a écrit : > gcc-3.2.2 + slack 9 + p4 2.6ghz (has sse/2) > > ./configure --prefix=/app/speex-1.1.4 --enable-shared --enable-sse > --with-ogg-dir=/app/libogg-1.1 >

> > 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

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

Jean-Marc, Are you sure that you don't need to add just -msse to enable the intrinsics rather than a full fledged -march=pentium3? I did some playing around and I can get intrinsics code to compile with -march=i686 -msse on linux with that. Check out:

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

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

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

Jean-Marc, Good catch on the debug mode. After compiling the same code in release mode it does appear to be using all the registers correctly. Give us a few days to integrate our run-time flags into 1.1.4 and I will let you know how are testing turns out. Aron Rosenberg SightSpeed At 08:54 PM 1/21/2004, you wrote: > > 1. Compile Error with regular mode (FIXED_POINT undefined)

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 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

Le mar 18/11/2003 à 17:39, Allen Drennan a écrit : > Speaking of video conferencing in conjunction with Speex, we are > currently beta testing a solution we developed that offers multi-point, > multi-party video and audio using the Speex engine for voice. > > http://www.wiredred.com/downloads/ecsetup.exe > > The fair and good audio settings are Speex narrowband, high quality

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

> 1. Compile Error with regular mode (FIXED_POINT undefined) at lsp.c line 104 > static inline spx_word16_t spx_cos(spx_word16_t x) . VS6 does not like > the inline keyword here. Removing it allows compiling. > > same with cb_search_sse.h line 34. It seems like your compiler simply doesn't like "inline". I suggest doing a -Dinline= which is what autoconf

Hi, I just released unstable version 1.1.2 that contains more fixed-point work. Though it's still not 100% complete, enough have been done to make it run in real-time on ARM. In order to do that, compile with --enable-fixed-point --enable-arm-asm. All narrowband modes work in real-time with complexity 1 (some work with higher complexity) and some wideband modes also work (up to ~20 kbps) at

Hi, Speex is progressing and I've started thinking about the next 1.2 release (don't hold your breath). Though the bit-stream won't change, the API likely will. The API for 1.1.x already differs from 1.0.x because the speex_encode and speex_decode now use shorts instead of floats. Now, since I'm changing the API anyway, I thought I might as well fix things that might be annoying

> 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

Le dim 31/08/2003 à 20:12, Daniel Vogel a écrit : > > This works really well for white noise reduction. However > > what I've noticed was the amplitudes of normal speech samples > > also get reduced. > > Noticed this as well recently. This is probably due to the AGC (Adaptive Gain Control) that's integrated with the denoiser. I'll try adding an option to