search for: _int

Assuming one prefers to use the speex_encode_int() and speex_decode_int() when available, but fallback to speex_encode() and speex_decode() if an older version if the lib is installed, how does one best make the determination? The only thing I can see to do is call speex_init_header() and look at the result. Even at compile time it seems one mus...

...com> writes: Malcolm> Well, for compile-time, I'd think that an #ifdef would do the Malcolm> trick. How? VERSION isn't included anywhere except in speex_init_header(), and I do not see any other symbols that encode the version.... That said, I looked at the code for speex_encode_int and friends since writing that. When compiled w/o --enable-fixed-point the _int functions do what the code I was looking at updating already does: convert each sample from short to float in a loop. And when compiled w/ --enable-fixed-point the non _int funtions do the opposite. It wouldn't m...

> Assuming one prefers to use the speex_encode_int() and > speex_decode_int() when available, but fallback to speex_encode() > and speex_decode() if an older version if the lib is installed, > how does one best make the determination? Well, for compile-time, I'd think that an #ifdef would do the trick. The only way you could do it at...

...de #defines for SPEEX_MAJOR_VERSION and so on in the header. If you're using autoconf you can of course try to link with one of the new functions, but just saying: #include <speex.h> #if defined(SPEEX_MINOR_VERSION) && (SPEEX_MINOR_VERSION > 0) /* code that uses speex_decode_int(); */ #else /* code that uses speex_decode(); */ #endif is more portable. So it might be worth doing that as well. FWIW, -r --- >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 'speex-de...

> 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 able to determine what they

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

> Note however that you'd still have to dlopen the library since can't > just do: if (call_is_allowed) > speex_encode_int(...); > > because then it won't link. Yeah, I understand that. I wonder if there's a way to "weak-link" against libraries on Linux/GNU-ld-so? The idea is that a symbol lookup/relocation isn't performed until the call is actually MADE, rather than merely referenced....

Quoting Segher Boessenkool <segher@kernel.crashing.org>: > > I wonder if there's a way to "weak-link" against libraries on > > Linux/GNU-ld-so? The idea is that a symbol lookup/relocation isn't > > performed until the call is actually MADE, rather than merely > > referenced. > > That's the default behaviour. No it's not. The

...ork_for_me() call :) Jean-Marc Le dim 16/05/2004 à 16:42, Malcolm Baldridge a écrit : > > How? VERSION isn't included anywhere except in speex_init_header(), > > and I do not see any other symbols that encode the version.... > > Hrm, I take it then that speex_encode_int() exists in both 1.0 and 1.1, > then? I'd assumed that speex_encode_int() only existed in one of them. > Otherwise I've just put my foot in my mouth. :) > > Are you merely looking for the fastest turn-around time given a supply of > short integer sample data being presente...

I noticed that the operand commuting code in X86InstrInfo.cpp treats scalar FMA intrinsics specially. It prevents operand commuting on these scalar instructions because the scalar FMA instructions preserve the upper bits of the vector. Presumably, the restrictions are there because commuting operands potentially changes the result upper bits. However, AFAIK the Intel and GNU FMA intrinsics

Hi all, Just a quick question about the X86 instruction naming convention in LLVM. Most instruction names in LLVM are self-explanatory. Some are a little confusing. What is the difference between instruction MULSSrr and MULSSrr_Int? What does the suffix '_Int' stand for? Are these instructions exchangeable: "ST_F64m", "ST_FP64m", "ST_Fp64m" "ST_FpP64m32"? Any direction will be appreciated. Thanks a lot in advance. Bin

...ond this; changing the argument type to one of the main functions is a bad idea. It's true that the soname mechanism can take care of this on platforms that support it, but it's just confusing. I'd suggest doing something like we did with vorbis (but in reverse): Add new speex_encode_int() and speex_decode_int() calls that that take the short* argument (or a typedef that's definitely 16 bits). Leave the plain speex_decode() and speex_encode() functions taking floats, and make them a simple wrapper that does the conversion and calls the _int version. That way software writt...

hi, my environment... > sessionInfo() R version 3.3.2 (2016-10-31) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Debian GNU/Linux 8 (jessie) locale: [1] LC_CTYPE=ja_JP.UTF-8 LC_NUMERIC=C [3] LC_TIME=ja_JP.UTF-8 LC_COLLATE=ja_JP.UTF-8 [5] LC_MONETARY=ja_JP.UTF-8 LC_MESSAGES=ja_JP.UTF-8 [7] LC_PAPER=ja_JP.UTF-8 LC_NAME=C [9] LC_ADDRESS=C

...int stride, int arch) = { + clt_mdct_backward_c, /* ARMv4 */ + clt_mdct_backward_c, /* EDSP */ + clt_mdct_backward_c, /* Media */ + clt_mdct_backward_float_neon /* Neon with NE10 */ +}; + #endif /* HAVE_ARM_NE10 */ # endif /* OPUS_ARM_NEON_INTR */ # endif /* FIXED_POINT */ diff --git a/celt/arm/celt_ne10_fft.c b/celt/arm/celt_ne10_fft.c index b592f19..d354502 100644 --- a/celt/arm/celt_ne10_fft.c +++ b/celt/arm/celt_ne10_fft.c @@ -118,3 +118,29 @@ void opus_fft_float_neon(const kiss_fft_state *st, } RESTORE_STACK; } + +void opu...

...int stride, int arch) = { + clt_mdct_backward_c, /* ARMv4 */ + clt_mdct_backward_c, /* EDSP */ + clt_mdct_backward_c, /* Media */ + clt_mdct_backward_float_neon /* Neon with NE10 */ +}; + #endif /* HAVE_ARM_NE10 */ # endif /* OPUS_ARM_NEON_INTR */ # endif /* FIXED_POINT */ diff --git a/celt/arm/celt_ne10_fft.c b/celt/arm/celt_ne10_fft.c index b592f19..d354502 100644 --- a/celt/arm/celt_ne10_fft.c +++ b/celt/arm/celt_ne10_fft.c @@ -118,3 +118,29 @@ void opus_fft_float_neon(const kiss_fft_state *st, } RESTORE_STACK; } + +void opu...

...een asked, i've checked mailing list logs but ... I didn't figure out the solution for my question. I want to use basic functionnality of speex, only VAD, no pre/post filter, even no VBR. But i *really* want to use less mem/cpu i can. So in which format should i pass data to speex_encode(_int) , float or short ? I quickly looked at the source code and i saw the speex_encode doing float to short convertion but it has protected by some #ifdef so .. Easy question, i want to: - pass buffer to Speex in its native format - encode fast with low resource, avoid buffer convertion ......

Hello All, I extended the libNE10 optimizations for float towards mdct_backwards/opus_ifft. I am able to get about 14.26% improvement for Decode use case now on my Beaglebone Black. Please see [1] for measurements. Questions 1. Since this patch needs to go in after Encode [2] patch) should I submit this as patch series? 2. Since Jonathan Lennox posted intrinsics cleanup [3] patch, should

...: int speex_decode_bits(SpeexBits *inBits, SpeexBits*outBits). inBits is SpeexBits containing the bits we're interested in. outBits may be NULL. If not NULL, and inBits contains valid frames, they are written, one frame per call, to outBits. it would return the same values as speex_decode(_int). SpeexBits inBits, outBits; void *state; initialize: state = speex_decoder_init(&speex_nb_mode); process: speex_bits_read_from(&inBits, inBuf, inlen); for(i=0; ;i+=160) { if(speex_decode_bits(&inBits,&outBits)) break; /* do something with out...

...http://www.grandgent.com/spx/tgAudioCodec.zip I followed your recommendations and they worked fine with 1.1.0. However, I'm still having the same problem with 1.1.7 that I had the last time I tried to upgrade. I'm using the same code with both versions, except for calling speex_encode_int instead of speex_encode, and passing ints to speex_preprocess instead of floats. What happens is that the encoder gets into a bad state and everything sounds garbled after that point. I can restart the decoder, disable the preprocessor, and the problem still exists, so I think the problem is...

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 short to float and back. Jean-Marc -- Jean-...