search for: _ctl

...testenc needs to be fixed to use spx_int32_t instead of int. I'll change that. Jean-Marc Jim Crichton a ?crit : > st->highpass_enabled is typed inconsistently. It is "int" in the > structure, but "spx_int32_t" in the SET, GET cases in > nb(sb)_encoder(decoder)_ctl. The parameter is "int" in testenc.c, and > in the TI version ti\testenc-TI-C5x.c. This breaks for 16 bit platforms, > where "int" is 16 bits. > > The types in the state structure and the _ctl routines really should > match. For now, I have changed testenc-TI-C5...

Hi, I use speex 1.1.12 in my program, but I found a strange thing about Echo canceller. That is, I'll hear an explosion in a certain frequency inputing. And I use the echo canceller in 44100Hz sample rate, disable AGC and Denoise. Can you tell me what's wrong with me? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi everyone, I'm about to release version 1.2-beta1 (which I could have called 1.1.13), which includes many, many changes. It would help if everyone could give the svn version (http://svn.xiph.org/trunk/speex/) a try and see if it works fine. I'll check my email next week when I'm back from some vacations and if nothing bad has been reported, I'll make the release. Have fun,

Hi, Has anybody some information on on the "Redundant audio data" header in the speex rtp payload? Is this header always present? Is its value always the same? Can it be modified through some speex_*_ctl function? Thanks, Emmanuel -- ------------------------------------------------------------- Emmanuel Wauters Tel : (+32) 11 30 13 30 mailto:emmanuel.wauters@androme.com http://www.androme.be ANDROME NV Wetenschapspark 4 B-3590 Diepenbeek, Belgium

...n VBR or DTX mode? > At least that's why I kept it. Of course it *can* be used (and needs fixing). It just seems few people did :-) > So, what's the next step towards intergartion? I guess it should > be somehow made available from Speex API level, e.g. with > new speex_decoder_ctl() or speex_lib_ctl() request? I have > no idea about the best way here, and would appreciate your > advices. I don't think it should be a _ctl() call because there's too much potential for confusion. I would just keep it as a separate API call like you have. I'd tend to put it in...

...px_int32_t instead of > int. I'll change that. > > Jean-Marc > > Jim Crichton a ?crit : >> st->highpass_enabled is typed inconsistently. It is "int" in the >> structure, but "spx_int32_t" in the SET, GET cases in >> nb(sb)_encoder(decoder)_ctl. The parameter is "int" in testenc.c, and >> in the TI version ti\testenc-TI-C5x.c. This breaks for 16 bit platforms, >> where "int" is 16 bits. >> >> The types in the state structure and the _ctl routines really should >> match. For now, I have ch...

...of ps and noise. This really helped users to > improve the quality of their input, as they could clearly and > immediately see the effect of changes in the environment. > These data are now private and can't easily be extracted from an outside > program. Would it be possible to add _ctl calls to GET_PS, GET_NOISE, > GET_SNR etc? Would you accept patches which did this? One of the main reasons the struct is now private is that its content depends on whether Speex was compiled for fixed-point or floating-point. I'm not against making it possible to extract some information,...

...these optimizations for minimal ram usage in the main version? Maybe if Peter sends a Patch... Thanks, Alain Jean-Marc Valin escreveu: > Sounds like you did most of what you needed to do. Using a coverage > analysis tool might help you remove bits of code here and there (e.g. > unused _ctl() cases), but the main part is done. About the preprocessor, > there are some of the state variables that could instead be allocated on > the stack, but that's about as far as you can shrink things. > > Cheers, > > Jean-Marc > > Peter Ruckle a ?crit : >> I need...

I need to shrink speex so it will fit on an embedded processor along with some other code. The chip has only 20k of ram. I have done some work with libspeex.dsp by removing references to all modes but narrow band 8000 hz (submode 3). I used the defines: FIXED_POINT, DISABLE_FLOATING_POINT_API, DISABLE_VBR. I also removed the structures for the other submodes and the functions that they called.

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

Hi Drew, On 10/10/17 02:29 PM, Drew Allen wrote: > 2) Someone on this list might know better than I do on that one, but for > the new _ctl_va_list() calls, I believe the convention is for va_start() > and va_end() to appear in the caller rather than in in the va_list() > function itself. > > *My understanding is that it's impossible to pass ellipsis to another > function.* Basically, what I mean is that I *think*...

On Sun, May 16, 2004 at 06:03:47PM -0400, Jean-Marc Valin wrote: > 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...

> Sounds reasonable. You could also overload the existing speex_*_ctl() > calls to take SPEEX_GET_LIB_VERSION, SPEEX_GET_LIB_MAJOR_VERSION, etc. > > What people are really asking for here is a way to determine at for > conditional compilation (i.e. at configure time) what calls are > available. Runtime methods would be nice too, for prebuilts to be...

This small patch will make st->Zlast = Zframe, to allow applications access to an estimate of the signal-to-noise level. This used to be in there earlier, but was removed when Zlast was no longer used to compute Pframe. -------------- next part -------------- Index: preprocess.c =================================================================== --- preprocess.c (revision 10007) +++

...a graphical view of ps and noise. This really helped users to improve the quality of their input, as they could clearly and immediately see the effect of changes in the environment. These data are now private and can't easily be extracted from an outside program. Would it be possible to add _ctl calls to GET_PS, GET_NOISE, GET_SNR etc? Would you accept patches which did this?

...; >> >>> Hi, >>> >>> Has anybody some information on on the "Redundant audio data" header in >>> the speex rtp payload? >>> Is this header always present? Is its value always the same? >>> Can it be modified through some speex_*_ctl function? >>> >>> Thanks, >>> Emmanuel >>> >>> >> >> >> > >

Sounds like you did most of what you needed to do. Using a coverage analysis tool might help you remove bits of code here and there (e.g. unused _ctl() cases), but the main part is done. About the preprocessor, there are some of the state variables that could instead be allocated on the stack, but that's about as far as you can shrink things. Cheers, Jean-Marc Peter Ruckle a ?crit : > I need to shrink speex so it will fit on an embedd...

...st that's why I kept it. > > Of course it *can* be used (and needs fixing). It just seems few people > did :-) > >> So, what's the next step towards intergartion? I guess it should >> be somehow made available from Speex API level, e.g. with >> new speex_decoder_ctl() or speex_lib_ctl() request? I have >> no idea about the best way here, and would appreciate your >> advices. > > I don't think it should be a _ctl() call because there's too much > potential for confusion. I would just keep it as a separate API call > like you have...

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.

Alexander Chemeris wrote: > On 2/16/08, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: >>> Oh, you're right, inband handling is different, but it's a matter of one >>> flag, passed to functioin. Probably not that much to keep code DRY. >> Well, let's first merge your code and then we'll see about possible >> simplifications. >