similar to: Thread Safety

> 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

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

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

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

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

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

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)

Jean-Marc Valin wrote: > Never been tested but it should be. I don't use static variables (except > read-only which is OK). Are they actually read-only or are they initialized once? In the latter case, you need to protect the initialization section... <p>Segher --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To

Jean-Marc Valin wrote: > > Are they actually read-only or are they initialized once? In the latter > > case, you need to protect the initialization section... > > No, they're written to every time you enter the lsp_quant_* routines > below. The only reason why this isn't catastrophic is that even wrong > values (two threads writing at the same time) will only

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:

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

On Wed, 21 Jan 2004, Aron Rosenberg wrote: > A few things - > > 1. I think that run-time processor detection should not be included in Speex. That approach only works for environments where people are compiling their own code for their own use on their own machine. Some people want to ship binaries. To begin with, not everyone has a compiler installed on their machine and even among

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

Hello! The question is: "Does Speex support multiple channels?" Speex is reported to encode only mono and stereo signals. But I found 'nb_channel' defined in <speex_header.h> among the Public Attributes. Does this mean that it is also possible to store more than two channels in one single speex-file? Maybe it will be possible in the next future...? TIA -- Mch --- >8

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?

Not that I'm going to be doing this, but just out of curiosity, how well would speex perform for singing? I don't know if speex is specialized to the human voice, or the normal low-stress human voice. Does speex' performance change when dealing with shouting, etc? Have you ever tried jazz scat, or anything like that, cat? Just wondering. --- >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 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