similar to: No subject

Le ven 19/12/2003 à 09:38, David Siebert a écrit : > They claim to max out at 1,800 MFLOPs > And have a clock speed of up to 300 mhz. Are you kidding? Not only is this enough to encode/decode in real-time, but you can probably do ~50 channels (or more) at the the same time. Jean-Marc > Jean-Marc Valin wrote: > > >Tell me how fast these chips are, I'll tell you if

Le mer 31/03/2004 à 02:51, George Bratis a écrit : > I think that if you want to use a low cost dsp you must rewrite ti in > assebmly. > In our tests you will need 4-5 times more MIPS just compiling C code. You may need to rewrite 3-4 compute-intensive, but definitely not the whole thing. Jean-Marc -- Jean-Marc Valin http://www.xiph.org/~jm/ LABORIUS Université de Sherbrooke,

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

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

> 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

> If I decode to .wav, it works fine. However, if I decode to .raw, it > does not work (the decoded file when viewed on GoldWave on Windows > appears to be all noise. I've tried 16-bit, signed, unsigned, big > endian and little endian, mono and stereo PCM - none make a difference > - the decoded file always appears to be noise). Can you try manually swapping the bytes on

Hi, Do you get that problem with speex_nb_mode too (or only speex_wb_mode)? Jean-Marc Le lun 29/03/2004 à 05:35, Chris Flerackers a écrit : > Hi, > > I'm using speex 1.1.4 and when I query SPEEX_GET_SAMPLING_RATE > as in > speex_encoder_ctl ( m_pEncoderState, SPEEX_GET_SAMPLING_RATE, > &m_SampleRate ); > I get > 2 > The encoder is initialized with

> The st->zeta pointer isn't freed in the speex_preprocess_state_destroy() > function of the preprocess.c file (alloced in line 167). It's in Speex 1.1.4 > by the way. Oops... Thanks for letting me know. I'll change that for the next release (in the mean time, the fix is obvious). In case you're interested, I'm currently working on a reverberation suppression

> Reverberation suppression? Basically, it means that if you are in a room with lots of echo (long decay), I can reduce it a bit. > I guess this would help reduce local source echoes? I've never > _noticed_ that to be a problem in my use, but I would imagine that > using a notebook's built-in microphone, you'd get some echo off of the > screen and stuff [also from

> Hmm, How can I find that out? How much CPU would you expect it to > take? I don't know. It's been a while since I last played with that code, but I'd expect it to take less time. > I've been playing with oprofile, but I don't see it getting that > finely grained.. Can you make sure the time is spent in the VAD and not in the encoder or decoder (at the other

> > These numbers sound like a problem I has a while ago with the decoder. > > The VAD shouldn't take much CPU so I suspect there might be floating > > point underflows in some part, slowing down the Intel CPUs a lot (for > > some reason, the AMD CPUs seem to handle underflows faster). > > > > Hmm, How can I find that out? How much CPU would you expect

OK, so the problem doesn't seem to be the VAD specifically. Can you tell me how much audio you had in the test? It may be that nothing's wrong and the code just isn't so fast that you can do 100 channels. Or maybe it just needs a bit of optimization... Jean-Marc Le mer 31/03/2004 à 10:03, Steve Kann a écrit : > Jean-Marc Valin wrote: > > >If you set the denoiser

> 1) I was interested in fetching the default quality setting > fornarrowband: > speex_encoder_ctl(_encodeState, SPEEX_GET_QUALITY, &value); > > Unfortunately, the above fails with libspeex 1.1.4. The console > shows: > > warning: Unknown nb_ctl request: 5 Actually, I never implemented SPEEX_GET_QUALITY. It's not that usefule anyway, but I might do it in the

Actually, I prefer having the user explicitly specify --enable-sse because you might want to compile for other machines than what you have. Also, any idea what happens if the user already has CFLAGS=-O2 defined (and you add -O3)? Last thing, how do you check whether gcc accepts -msse? Jean-Marc Le ven 02/04/2004 à 00:40, Aron Rosenberg a écrit : > Here is code to add to configure.in

> I want to know if it is possible to do a real time acquizition and to > compresse in real time the audio input signal. By example, I have on my > demonstration card an audio linein input. If I send an audio source (PC > sound card output) on this input, does speex will be able to compress > this signal in real time and to store it in a hard disk integrated to > the

Hi, I'd just like to point out that Speex recently switched to Subversion and that the anonymous checkout is now: svn co http://svn.xiph.org/trunk/speex/ While the anonymous CVS still works, it is no longer being updated, so you should stop using it. Jean-Marc -- Jean-Marc Valin http://www.xiph.org/~jm/ LABORIUS Université de Sherbrooke, Québec, Canada -------------- next part

Le ven 16/04/2004 à 16:39, Kenji Chan a écrit : > Ok, I'm using 1.1.4, so I should pass signed short(wav data) directly to > speex_encode()? First, I'd like to ak why you want to use 1.1.4. If you don't need the new features (fixed-point or preprocessor), you should probably stick to 1.0.3, which has received more testing. If you choose to use 1.1.4, you need to send shorts to

OK, I'll try to do *something* about it. It'll be either "support the 1.0 ABI" or "make sure the link will break". While the former would be nice, I'm not sure I want to really want to force 1.2 to have the same ABI as 1.0.x. More on this when I have some time to think about it. Suggestions are welcome. Jean-Marc Le lun 19/04/2004 à 02:18, Conrad Parker a

Hi everyone, Due to popular demand, I'm releasing 1.1.5 which is now API-compatible with 1.0.x. The short* version of the functions now have a _int suffix, as in speex_encode_int. I recommend using these functions if you are using 1.1.5 as it will make your code work better with the fixed-point implementation. It's also simpler to use because you don't have to convert samples from