similar to: [LLVMdev] X86 instruction encoding

On Mon, Apr 19, 2004 at 02:46:44AM -0400, Jean-Marc Valin wrote: > 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.

Hi, i know this question has already been 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

[sorry for the loss of proper attributions, this is from two messages]: [Me] >This is something I've encountered in trying to make a particular > asterisk application handle properly IAX2 frames which contain either > 20ms of 40ms of speex data. For a CBR case, where the bitrate is > known, this is fairly easy to do, especially if the frames _do_ always > end on byte

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

>>>>> "Malcolm" == Malcolm Baldridge <speex@paypc.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

Hi all, I noticed that the x86 backend tends to emit unnecessary vector insert instructions immediately after sse scalar fp instructions like addss/mulss. For example: ///////////////////////////////// __m128 foo(__m128 A, __m128 B) { _mm_add_ss(A, B); } ///////////////////////////////// produces the sequence: addss %xmm0, %xmm1 movss %xmm1, %xmm0 which could be easily optimized into

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 must compile a test app that outputs that data and then

I have (finally) posted my Speex wrapper classes. They are at: 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

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

Optimize opus decode (float only) use case using ARM NE10. Mainly effects opus_ifft and ctl_mdct_backward and related functions. Work based on previous Encode optimization using ARM NE10 library. TBD: Add commit id of upstream Encode NE10 optimization patch so that users have reference of how to enable this optimization Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at

Optimize opus decode (float only) use case using ARM NE10. Mainly effects opus_ifft and ctl_mdct_backward and related functions. Work based on previous Encode optimization using ARM NE10 library. TBD: Add commit id of upstream Encode NE10 optimization patch so that users have reference of how to enable this optimization Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at

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

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

On Sun, Apr 25, 2004 at 04:18:16PM +0200, crazylord wrote: > Hi, i know this question has already been 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

On Mon, Apr 26, 2004 at 01:32:53AM +1000, Kenji Chan wrote: > I always think short is better over float, because most of the time we don't > get float form data, from, e.g microphone / wav files It really depends on your framework. Hardware generally uses integer samples, but a number of newer software systems use float. On modern host cpus it's just as fast and you don't

Hi Steve, Though it may work (haven't thought about all the details), I think it would be much more messy than just using a codec abstraction layer (the one in Speex or a custom one). I don't understand why you don't like that idea. Jean-Marc > And later, it might also be useful to have an API which takes a bunch > of SpeexBits, and gives the caller a way to split up the

Hi, The attached patch includes a fully working patch for the resampler, including manual SSE optimizations for the single target. I've tested up and downsampling, changing the filter quality on the fly, changing sampling speed on the fly, multichannel resampling, _float and _int versions in both floating and fixed point and resetting the resampler. They all give the same results as the

I built the CVS version of the Speex library - v1.2 it calls itself. Asterisk seg faults trying to use codec_speex.so. I'll have a look to try to fix it, but thought I'd just ask if anyone else knows what needs to be done? Steve

I always think short is better over float, because most of the time we don't get float form data, from, e.g microphone / wav files <p>-----Original Message----- From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org] On Behalf Of Conrad Parker Sent: Monday, April 26, 2004 12:58 AM To: speex-dev@xiph.org Subject: Re: [speex-dev] speex_encode / speex_encode_int ... already sorry

Hi, While most of the native functions take float[] array as input, why the function speex_preprocess(...) can only accept short[] array? How do I call this function if I have float[] array inputs? Do I need to convert the floats to Integers back and forth? Thank you in advance. Long Deng -------------- next part -------------- An HTML attachment was scrubbed... URL: