similar to: Version 1.1.5 is out - API change

Hi, I've tried the same configure options on my system and it doesn't crash. I have the same glibc and gcc 3.3.2 (can you see if a newer gcc works?). Also, could you explore a bit with different options so we can narrow it down a bit. For example, does it work with the default CFLAGS or without --vbr or --dtx. Last thing, maybe it's the file. If so, please send me the smallest sample

Actually, the best thing do to would be to use __int64 *unless* it's not supported. So there needs to be a configure check... Jean-Marc Le mar 01/06/2004 à 14:50, Kenji Chan a écrit : > I emailed Jean-Marc the arch.h about one week ago, not quite sure > whether he actually received that email. > > > > Anyway, here I have an improved version of arch.h that I

Hi, Right now, I'm thinking of adding a speex_lib_ctl() call that would support SPEEX_GET_VERSION (and return a string) or SPEEX_GET_MAJOR_VERSION and SPEEX_GET_MINOR_VERSION (and return ints). I'm open to other suggestions though. If there's anything you'd like to see in the API for 1.2, say it now. ...and no, I won't add a speex_do_all_the_work_for_me() call :)

Hi, I suspect something related to endianness or word size here. Can you check that the encoded files end up the same size? Also, what if you encode on the Pocket PC and decode on a desktop? Maybe if you encode a small wav file on both pocket PC and desktop using default options and send me the results. Jean-Marc Le lun 24/05/2004 à 09:52, Asheesh Vashishtha a écrit : > Hi all, >

I'd say check the result just after denoising (try without denoising too). Also make sure you've got the right number of samples and all. I can't say much with the info you're giving me. Jean-Marc Le ven 28/05/2004 à 16:29, Alex Wang a écrit : > I just download the 1.1.5. And it is working well. I try the xxx_int > functions at least it works. But I did not find the

> The problem is that GCC 3.3.x made a change which requires changes to > Speex's autoconf files to support the new features in Speex 1.1.4. A > discussion to determine the best approach to fix the problem (while > maintaining portability) is in progress. For more information, see the > thread [speex-dev] libspeex/SSE Intrinsics with GCC 3.3.x at >

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, Here's a couple things to look at: 1) Are you using your own encoder and decoder? If so, try with speexenc and speexdec. 2) Is PocketPC big endian? If so, try defining WORDS_BIGENDIAN when compiling Speex. 3) The "This doesn't look like a Speex file" error sounds very suspicious because it only involves looking at the first chars of the first packet and looking for the

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,

> 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