similar to: [PATCH] Another kissfftr exit call

I pulled the test directory from 2003, but everything else from 2005. The 2005 files have more ?cross-compiling? targets than the 2003 ones. I fixed the various missing files in the new 2008 projects (misc.c and one other other are gone now). The only thing you could do which would make them more compact would be to get rid of the subdirectories under each vs-version. There is no real need for

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: speex_vs2008.diff Type: application/octet-stream Size: 165590 bytes Desc: speex_vs2008.diff Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20071127/08917736/speex_vs2008-0001.obj

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: speex_vs2008_part2.diff Type: application/octet-stream Size: 11265 bytes Desc: speex_vs2008_part2.diff Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20071128/136ce70d/speex_vs2008_part2-0001.obj

We just came across an occasional crash with the Win32 Assembly patch I sent in earlier, so hold off on applying it until we send an updated version. Aron Rosenberg SightSpeed http://www.sightspeed.com <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to

Here is code to add to configure.in to do what you want. It preserves CFLAGS and uses that var to hold the sse enable flags. You can subset this under the exisiting AC_ARG for sse or just make it do it all the time. If you notice the i?86, that means any x86 platform target will have it enabled. You can change that i686, but keep in mind that some distros compile/target for i386 on the glibc

In speex_alloc.h The following code #ifdef USE_ALLOCA #include <alloca.h> #endif should be: #ifdef USE_ALLOCA #ifdef WIN32 #include <malloc.h> #else #include <alloca.h> #endif #endif for visual studio at least. Not sure about mingw Aron Rosenberg www.sightspeed.com

Ok! If there are indeed cross-compiling targets defined, then vs2005 projects probably should be maintained. In any case, this is all up to Jean-Marc, since he's the one that actually has authority to change it :) Jean-Marc -- what's your opinion? On 11/28/07, Aron Rosenberg <arosenberg@sightspeed.com> wrote: > > I pulled the test directory from 2003, but everything else

Greetings, <p>my apologies for putting this trash in the mailing list but the topic about SSE run-time option interested me pretty much. Looks like some people is really experienced on the topic. I would really appreciate if somebody could point me to good resources about SSE and Altivec (not necessarly on the net, I'm ready to invest some money if necessary). I already have intel

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

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

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:

The VS2005 project files are known to not be up-to-date, so I can understand that you'd need to fix some things. Can you verify with an import of the VS2003 project files, that there is no need for any fixes, and just works after importing? Managing multiple project files should be minimized if at all possible. If a straight import of vs2003 project files can be done without any changes

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)

I wish Speex could come with instructions on how to build libspeex_armce.lib. ________________________________ From: speex-dev-bounces@xiph.org on behalf of speex-dev-request@xiph.org Sent: Mon 11/13/2006 3:01 PM To: speex-dev@xiph.org Subject: Speex-dev Digest, Vol 30, Issue 15 Send Speex-dev mailing list submissions to speex-dev@xiph.org To subscribe or unsubscribe via the World

Is Speex internally thread safe? <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.

Hi everyone, As you may have guess, Speex 1.2 is slowly approaching, though there's still a lot left to do so I can't say how long it'll take. I thought this was the right time to ask if there's anything missing or that can be improved to make 1.2 better. At this point, it can't be anything major, but there are still some changes that are possible, e.g: - Improving some

All, Attached is a patch that does two things. First it makes the use of the current SSE code a run time option through the use of speex_decoder_ctl() and speex_encoder_ctl It does this twofold. First there is a modification to the configure.in script which introduces a check based upon platform. It will compile in the sse assembly if you are on an i?86 based platform by making a

> 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

Jean-Marc, There is a big difference between SSE and SSEFP. The SSEFP means that the CPU supports the xmm registers. All Intel chips with SSE support do, however no current 32 bit AMD chips support the XMM registers. They will support the SSE instructions but not those registers. You are right about the SSE2 not being used. The AMD Opterons are the first AMD CPU's which support

On Mar 29, 2004, at 5:05 PM, Jean-Marc Valin wrote: > Can you try manually swapping the bytes on the raw output and see if > you > get something useful (I think by default wav is always little endian > while raw is native endian)? Well, my apologies. Apparently I got confused when trying all the different formats and somehow skipped little endian. The decoded raw file is in