similar to: opus_quant_all_band_working

Jean-Marc, At 08:12 PM 4/1/2005, Jean-Marc Valin wrote: >I'm not even sure what WMMX is, This is just a short name for the MMX/SSE extensions/intrinsic functions for the intel XSCALE processors. Most of the WMMX instructions have MMX/SSE equivalents, plus there are a few other interesting functions. We have been thinking about doing WMMX optimizations of the various speex asm functions,

Hi everyone, I have profiled Opus on AArch64. I just run opus_demo with some pcm files. Following is time proportion of FFT with different bitrate. Bitrate | Time cost by FFT/iFFT 24kb/s | 15% 48kb/s | 15% 96kb/s | 13% Any comment? I want some data close to real application, any suggestion? Thanks, Phil Wang -------------- next part -------------- An HTML attachment was scrubbed... URL:

I work with the Microsoft Embedded Visual C++, and i don't have a linux machine with me. I need to have the best performance in order to run my application for the Intel XSCale with MMX. I don't know if i can compile for this processor with the best performance using the Microsoft compiler. I would like a help regarding how to get or build this .obj. Thank you. Cesar Bremer Pinheiro

Hi, I'm not even sure what WMMX is, so I have no idea how to use it. For sure you would at least need to write some assembly. As for the current inline assembly parts (for the ARMv4 arch), you would need to convert them to VC++. It shouldn't be too hard, just push/load the registers at the beginning and then save/pop at the end. It's just the small macros (in fixed_arm4.h) that you

These were used because the entropy coder originally came from outside libcelt, and thus did not have a common type system. It's now undergone enough modification that it's not ever likely to be used as-is in another codec without some porting effort, so there's no real reason to maintain the typedefs separately. Hopefully we'll replace these all again somedate with a common set

Hello All, I've been studying dovecot for replacing my company's current system and I got a little worried about an aspect of the dovecot's design. I was surprised that dovecot doesn't use prefork for its mail processes, forking a new processes for each new client connection. Talking in the #dovecot channel I was gave a scenario of a system supporting ~40k users with 4 servers

Hi, I just realized that clang produces Thumb-2 instruction in code even when older CPU type which doesn't suport Thumb-2 is specified. Here is output: # /opt/llvm/bin/clang -S -ccc-host-triple arm-unknown-freebsd -mcpu=arm926ej-s -mfloat-abi=soft -v -o rrx.S rrx.c clang version 3.0 (http://llvm.org/git/clang.git 98138cdfdee05c0afbab2b209ce8cfe4a52474e1) Target: arm-unknown-freebsd Thread

Hi, I'm fairly new at poking around in llvm internals so if you find misconceptions / problems with the below let me know, this is just how I've understood this so far. When doing a build which uses functionality from LinkModules to combine bitcode from different versions of LLVM, or between LLVM-GCC (I know) and Clang, I've noticed that multiple warnings which sometimes seem

Hi > I just realized that clang produces Thumb-2 instruction in code even when older CPU type which doesn't suport Thumb-2 is specified. > > Here is output: > > # /opt/llvm/bin/clang -S -ccc-host-triple arm-unknown-freebsd -mcpu=arm926ej-s -mfloat-abi=soft -v -o rrx.S rrx.c > clang version 3.0 (http://llvm.org/git/clang.git 98138cdfdee05c0afbab2b209ce8cfe4a52474e1) >

Hi everyone, I'm currently looking into using speex in an embedded project using an ST ARM-device (STR9 family) just with internal memory (96kbyte) and no O/S. Does anyone know if the optimizations included in the code for ARMv4 and ARMv5e are appliable to this device? I would also need to strip down libspeex pretty hard to fit into the available memory. I just want to use a fixed bitrate

Hi Timothy, It requires some extra effort if twiddles and input/output have different bit width. Since Opus uses int32 for twiddles, we are going to do the same thing. Thanks, Phil Wang -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not

Hi Jean-Marc, I have implemented fixed-point FFT with 32-bit twiddles. Now I want to evaluate the accuracy, what method does Opus use? I use function implemented inside Ne10 to calculate SNR. Any comment? | size | SNR (dB) | | 16 | 82.558587 | | 32 | 83.530298 | | 60 | 80.292433 | | 64 | 82.752950 | | 120 | 79.625077 | | 128 | 83.091260 | | 240 | 79.555263 | | 256 |

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We just released Opus 1.1-rc, which should be the last step before the final 1.1 release. Compared to 1.1-beta, this new release further improves surround encoding quality. It also includes better tuning of surround and stereo for lower bitrates. The complexity has been reduced on all CPUs, but especially ARM, which now has Neon assembly for the

Hello, I've been working on optimizations for ARMv5E architecture and Cortex-A8 for both decoder and encoder and my company is agree to contribute to upstream. Could you tell me how to do it ? Best regards, -- Aur?lien Zanelli Parrot SA 174, quai de Jemmapes 75010 Paris France

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We just discovered some issues with the ARMv5E and Neon optimizations and have released 1.1-rc2 to address those. Other platforms are unaffected. Jean-Marc On 11/26/2013 02:06 AM, Jean-Marc Valin wrote: > We just released Opus 1.1-rc, which should be the last step before > the final 1.1 release. Compared to 1.1-beta, this new release >

On 28/12/14 11:04 PM, Phil Wang wrote: > It requires some extra effort if twiddles and input/output have > different bit width. Since Opus uses int32 for twiddles, we are going > to do the same thing. Actually, the existing Opus code has 16-bit twiddles, mostly because it makes it possible to use smulwb on ARMv5E. That being said, I agree that for Neon it makes sense to use 32-bit

Hi Tobias, I don't know if you've noticed, but ST actually released an optimised port of Speex for their chip (see mailing list archive). About disabling wideband, that can be done by defining DISABLE_WIDEBAND. You probably also want to define DISABLE_VBR and DISABLE_FLOAT_API. As you noted, you can also disable more than half the codebooks. That being said, I think adding a bunch of

Please ignore my previous mail and patch, there is a new version :). Patch changes are: - Use MAC16_16 macros instead of (sum += a*b) and unroll a loop by 2. It increase performance when using optimized macros (ex: ARMv5E). A possible side effect of loop unroll is that i don't check for odd length here. - Add NEON version of FIR filter and autocorr - Add a section in autoconf in order to

optimizations done for this CPU architecture. Whether it is in-line assembly or assembly optimization of function (Eg: celt_pitch_xcorr_arm.s), or using intrinsics, it is still some optimizations. So, I don't understand your perspective. I really thought about this for the most amount of time... could you please suggest an alternative here?.. Because I'm really out of ideas in this area

I wrote a proof of concept regarding the cpu capabilities runtime detection and choice of optimized function. I follow design which had been discussed on IRC. Also, i notice a little drawback: we must propagate the arch index through functions which don't have codec state as argument. However, if it's look good, i will continue to implement it. Best regards, -- Aur?lien Zanelli