similar to: XScale realtime encoding possible?

Jean-Marc Valin wrote: > Hi, > > I have replaced most (but not all) of the float operations by integer > operations, but it seems like the remaining ones take a long long time > when emulated in kernel space (hence high system time). The other > problem is that I don't have access to an ARM-based device (anyone wants > to send me one?), so I'm doing all this blind...

Hi, I have replaced most (but not all) of the float operations by integer operations, but it seems like the remaining ones take a long long time when emulated in kernel space (hence high system time). The other problem is that I don't have access to an ARM-based device (anyone wants to send me one?), so I'm doing all this blind... If you'd like to help, it can also accelerate things.

Hi, I just released unstable version 1.1.2 that contains more fixed-point work. Though it's still not 100% complete, enough have been done to make it run in real-time on ARM. In order to do that, compile with --enable-fixed-point --enable-arm-asm. All narrowband modes work in real-time with complexity 1 (some work with higher complexity) and some wideband modes also work (up to ~20 kbps) at

> I got the usage of --abr wrong before, (28 = 28 bits per second :) > I'm also assuming quality=0/comp=0 produces a reasonable output. Actually, --abr overrides --quality. Otherwise, --quality 0 would be bad quality. > 3 mins, 39 seconds is still a way off realtime, for a 60 second clip, > but it's a lot closer than 1.1.1 got. > > What still worries me though, is

Jean-Marc Valin wrote: > At this point, if you want to help, the best way would probably to try > tracking done what part of the code is responsible for the high system. > Once this is identified, we'll have a much better idea. > > I managed to log on the XSCALE 400 on handhelds.org. It helped, but I > can't do everything with it (and by attempts at profiling failed). I

> > looks like its more like 3000 times slower. This means that all of the > > float operations must be removed for the code to work properly. ...or > > maybe there's a way to make the emulation in a library instead of making > > the kernel trap illegal instructions. > > Is it a long job to remove the remaining floating point ops? Is it likely > to be

Hi All, ?? I am a new member to the vorbis-dev mailing list. i hope that u receive the help that i've been searching for. I need to compress audio samples captured by wireless sensor node (16-bit PCM at 8Khz). can i use vorbis i such an embedded system environment that has the following HW/SW specifications: -416 MHz Microprocessor(ARM architecture, Intel Xscale family) -32 MB RAM Beside

Hi there, sorry for troubling everybody once again, I've got a problem rewriting Sarkar's function for rewriting the tick locations in a logaritmic way (s. http://lmdvr.r-forge.r-project.org/code/Chapter08.R): His example works for log 2 but I need log e (natural logarithm). My problem is that if I replace 2 with "e" (using paste()), I get the error message that the location

Jean-Marc Valin wrote: > Hi, > > I just released unstable version 1.1.2 that contains more fixed-point > work. Though it's still not 100% complete, enough have been done to make > it run in real-time on ARM. In order to do that, compile with > --enable-fixed-point --enable-arm-asm. All narrowband modes work in > real-time with complexity 1 (some work with higher

Hello Greg If money isn't a problem Intel has an optimized compiler for eVC and XScale processors http://www.intel.com/software/products/compilers/techtopics/PCA_Optimization_WP.pdf If you have any luck getting the eVC compiler closer to realtime I'd really like to know. I'm still far from realtime when using Speex 1.1.3 on a HP iPAQ (Intel pxa255). Best regards Bjoern D.

Good afternoon, I am trying to create a plot where the bottom and top axes have the same scale but different tick marks. I tried user-defined xscale.component function but it does not produce desired results. Can anybody suggest where my use of xscale.component function is incorrect? For example, the code below tries to create a plot where horizontal axes limits are c(0,10), top axis has ticks

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,

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

Le dim 09/11/2003 à 14:33, Steve Kann a écrit : > Just out of curiosity, has anyone profiled the difference between the > floating point and fixed point implementations on processors with > decent floating point support? (i.e. x86, PPC). On recent x86 processors, floating point is faster than fixed-point. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS

Hi, I just did some experiments and it seems like the high system CPU time is not due to one specific part of the code, but rather to the extreme inefficiency of float emulation under Linux. I was expecting float emulation to run something like 30 times slower than integer, but it looks like its more like 3000 times slower. This means that all of the float operations must be removed for the code

Hi, Does samba require gawk, awk, perl, cc to compile? Or is it possible to just use the gcc compiler to build it. I want to build samba on xscale processor which has aminimal file system with native gcc compiler. It doesn't has perl or gwak etc. -Thanks, Rajesh

Hello! I posted a feature request at lattice page on r-forge at https://r-forge.r-project.org/tracker/index.php?func=detail&aid=1127&group_id=638&atid=2570 , but I decided to duplicate it here to make sure that I understand everything correctly. I would like to slightly change the way my plot axis labels look alike based on custom extra arguments to xyplot and bwplot. Right now these

MAL wrote: > > I don't know how to profile code (yet), but i'm about to go find out. > > Is it possible to profile the code on my x86 workstation, or does it > absolutely have to be run on the machine? ARM emulator anyone? :) <p>Intel designed performance monitoring hardware into the XScale. They also have a profiling tool called VTune that consists of some

Jean-Marc Valin wrote: > Hi, > > I just did some experiments and it seems like the high system CPU time > is not due to one specific part of the code, but rather to the extreme > inefficiency of float emulation under Linux. I was expecting float > emulation to run something like 30 times slower than integer, but it > looks like its more like 3000 times slower. This means that

Jean-Marc Valin wrote: >>>looks like its more like 3000 times slower. This means that all of the >>>float operations must be removed for the code to work properly. ...or >>>maybe there's a way to make the emulation in a library instead of making >>>the kernel trap illegal instructions. >> >>Is it a long job to remove the remaining floating point