similar to: Fixed-point AGC, snapshot

Manisha, I'm still here. :-) Here's the function: // Returns the average power level in the given signal float getPower(signed short int *signal, int numSamples) { int i; float amp; float powerSum = 0.0f; for (i = 0; i < numSamples; i++) { amp = (float) abs(signal[i]); powerSum += amp * amp; } return powerSum / (32768.0f * 32768.0f *

I think you'll have to modify Speex to get the functionality you're looking for. I've made a few simple modifications to the AGC to prevent it from 1) exceeding a specified level of amplification and 2) enable and disable adaptation, so I can freeze it at a certain level while speech is not detected. It's mostly just a matter of doing this at the end of speex_compute_agc():

agc_gain seemed to fit with the idea of what I wanted to do, it was easy to understand its units and behavior, and freezing it produced the desired results. Also I wanted to cap it, so that's done at the same place, and that definitely works. All I want to do is be able to freeze AGC adaptation and put an upper bound on the AGC (for example, 2x amplification). Both of these things seem

Hi, where I can found that patch? Thanks Seif 2008/7/16 Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> > Hi Michael, > > Thorval Natvig posted an experimental patch to get the AGC working in > fixed-point. Can you try that and see if it works well? > > Jean-Marc > > Michael Evseev a ?crit : > > Hello All, > > > > > > > >

On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > Alexander Chemeris wrote: > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > > > I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, > > > and there aren't any obvious artifacts. I also did a 16=>16 test, and the > > > results are delayed

Hi, The attached patch fixes an incistency in my earlier patch. Whereas the rest of the AGC ctls are in dB, GET_AGC_GAIN was linear. This patch fixes that. It also changes the API for _GET and _SET_AGC_LEVEL to use a int32 instead of a float, meaning we don't need to do a API change when we get a fixed point AGC. Best regards, Thorvald -------------- next part -------------- ---

Hello All, I'm using speex codec in ARM based embedded project and really satisfied by its performances and quality (thanks a lot for speex development team for great work!). I'd like to add AGC functionality and as I actually understood it is not supported in FPU-less platforms. Is it correct? If it is, do you have any updates of preprocessor or an experience to run AGC in

I vote for splitting 'em off and documenting the great features of each. I've been using the codec for a while now and would be more likely to dig in to the additional features if they were offered as separate components so I could use them with other audio projects (as well as being more likely to use those features in speex, simply because they would be easier to dig in to at

Alexander Chemeris wrote: > Hi, > > On 5/27/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> And here's a patch for Intel Math Kernel Library. This allows commercial >> users of Speex to use a high-speed FFT library that isn't GPL'd. (You do >> need to pay for it though). This is 3 times faster than the default FFT in >> speex, and

Hi, Here are some questions from user point of view. :) On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, > and there aren't any obvious artifacts. I also did a 16=>16 test, and the > results are delayed by 10ms and within +/- 1 (basically, rounding errors > from the FFT). Do

On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > > > Yes, I plan to use it in a VoIP environment if I can get latency reduced to > > > an acceptable level :) > > > The latency depends directly on the overlap parameter, which also controls > > > the quality. Higher quality => higher latency. You could set the overlap to > > > 0,

Alexander Chemeris wrote: > Hi, > > Here are some questions from user point of view. :) > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, >> and there aren't any obvious artifacts. I also did a 16=>16 test, and the >> results are delayed by 10ms

Thorvald, re: At 03:18 AM 1/6/2006, Thorvald Natvig wrote: >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... >And the addresses were not properly aligned :( From a bit of googling, >this seems to be a thread problem, as the gcc just maintains 16-byte >alignment of the stack -- if the start function of the thread had >misaligned stack, the misalignment

Hi, Attached is a patch which enables FFTW3 to be used by libspeexdsp. Using SSE, the FFT code is more than twice as fast, and it's 50% faster even without SSE. To enable the library, you'll need to call configure with '--with-gpl-fftw3'. Based on the benchmarking we did, this also changes the default FFT to smallft for floating point implementations when not using FFTW3.

Tom, Thorvald, Could one of you submit the details to the gcc bugzilla so it gets fixed? BTW, is 4.0 affected? Jean-Marc Le vendredi 06 janvier 2006 ? 17:13 -0800, Tom Harper a ?crit : > Thorvald, > > re: > At 03:18 AM 1/6/2006, Thorvald Natvig wrote: > >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... > >And the addresses were not properly

Jean-Marc Valin wrote: > Thorvald Natvig a ?crit : > >> I see you're changing the jitter buffer around quite a bit. Could you >> let us know when it's ready for general testing? (At the moment it >> doesn't handle missing packets at all) >> > > While I'm not completely done yet, I thought the current version was > working. Can you tell

Steve, You're right. The AGC gain does not max out when using VAD (via the preprocessor). So instead of not transmitting when the AGC max gain is reached, I now do this instead: Start the call with VAD enabled and AGC disabled. When speech is detected, disable VAD (if 100% continuous transmission is desired for the call) and enable AGC. This seems to be working reliably so far. However,

It seems that speex jitter buffer is tightly coupled with SPEEX codec [we have to give a speex decoder instance to JB]. It would be better if we could use it with any codec, like speex preprocessor and AEC. What are the any paper/theory/algorithms behind current ADAPTIVENESS of speex JB? Links to those algo/papers would help to understand better. -- Shantanu --- Thorvald Natvig

Duane Storey a ?crit : > Actually, it might just be an OS "feature".. On most linux and mac > platforms, the memory managers align memory on proper boundaries -- this > doesn't occur on most versions of windows. I don't have all the code in > front of me, but it's possible that it's simply a side effect of windows not > aligning the memory, and an

On 8/23/07, Thorvald Natvig <speex@natvig.com> wrote: > Jean-Marc Valin wrote: > > Duane Storey a ?crit : > >> Actually, it might just be an OS "feature".. On most linux and mac > >> platforms, the memory managers align memory on proper boundaries -- this > >> doesn't occur on most versions of windows. I don't have all the code in >