similar to: Problem with the patch

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:

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

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)

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

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

> 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

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

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.

So we ran the code on a Windows XP based Atholon XP system and the xmm registers work just fine so it appears that Windows 2000 and below does not support them. We agree on not supporting the non-FP version, however the run time flags need to be settable with a non FP SSE mode so that exceptions are avoided. I thus propose a set of defines like this instead of the ones in our initial patch:

> 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

Hello All, I was wondering what the theoretical ramifications where of re-encoding an already decoded Speex stream. This would be used to mix a live stream of several Speex end-points for a group-conferencing product? Would there be a significant impact on the quality - Should I set bit-rate higher on the re-encode side? Or is there a fancy way to mix the encoded samples?

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

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

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

Here are our notes on 1.1.4 testing on Windows 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. 2. Compile Error with quant_lsp.c line 55. M_PI is undefined. Either it needs to be included

Jean-Marc and others, We are using Speex inside our Video Conferencing application and have some questions about the trade-off of complexity vs bitrate. A little background information is needed: 1. For us the actual bit-rate isn't that big a deal. Speex running at 14kbps or 8 kbps is minor compared to the video traffic running at 128, 256 or 384 kbps. 2. We care a little about

Jean-Marc, >I'm still not sure I get it. On an Athlon XP, I can do something like >"mulps xmm0, xmm1", which means that the xmm registers are indeed >supported. Besides, without the xmm registers, you can't use much of >SSE. In the Atholon XP 2400+ that we have in our QA lab (Win2000 ) if you run that code it generates an Illegal Instruction Error. In addition,

I had a quick look at the patch. Could the problem just be that you don't backup the eax/ebx/... registers and then the compiler expects that whatever value was there before the asm is still there? Le mer 22/10/2003 à 16:55, Aron Rosenberg a écrit : > 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

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

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