similar to: Fixed point version.

Hmm, what these instructions do? (I know nothing about ARMs; I have some knowlege about x86 assemblers and programming). Cant we use pure standard C++ or Java? Does Speex work with fixedpoint math? (As far as I know Java on 6600 has no builtin floatingpoint, there is emulation class somewhere on the net, but it is probably painfully slow.) I do not know if this processor has builtin

hello, I have recently compiled speexenc for WinCE/StrongARM SA-1110-processor. It seems to run with no errors, however the encoding time is very slow - 10 seconds of speech takes aprox 3 minutes to encode. Even though the target architecture is significantly less powerfull than a standard PC, I am trying to figure out why it is this slow. Does speex use floatpoint calculations? The input raw

Actually, we have a integerized version of the vorbis libraries that are available, royalty free, with a simple attribution requirement. These libraries are 100% C code and run faster than real time on a cirrus 7312-74mhz processor (arm core). My guess is they should run at about 20-30% cpu utilization on a strongarm/200. Monty has this same code, but his version doesn't play b4 content real

A few months ago, there was some discussion about adding fixed-point support for iPAQ's StrongARM to Ogg Vorbis (whether and how it's possible, that is). Has anybody tried this yet ? Gregor --- >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 'vorbis-dev-request@xiph.org'

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

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

Thanks very much. You mean both encode and decode simulateusly (duplex)? Could you test the Java version (jspeex) on that iPaq too? (I do not have anything other than very fast PC, so I cant do this...) And, in phone, the mic can record not only the users speech but also voice from the other side (from speaker)... Does this make compression harder or the result worse? How can this impact

Hi , I'm a software developer. I'm searching a codec for speach using a xscale PXA263, i would like to know if speex 1.04 is good for this hardware. Do you develope the codec using intel specification or intel primitives "IPP 4.0" ? Thank you very much in advance Best regards, Pavel Ivanov --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

I am interested in using Speex in an embedded system built around an ARM microcontroller. I have seen other posts indicating that Speex can run in real-time on some iPAQ PDA's, but these are using a StrongARM 166MHz processor. I'm looking more at the chips from Atmel (SAM7), Philips (LPC2xxx), and TI (TMS 470), which are ARM7TDMI with on-chip SRAM and flash, running at speeds of 33 to

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

As Linux is starting to apperar on handhelds the tought of having a portable Vorbis-player is everpresent in my mind. However, one things worries me... A user running linux on his (ipaq?) PDA reported skipping and halted playback using mpeg123. Apparently this was caused by lack of processor resources because mpeg123 was programmed for a FPU-enabled CPU. (Thus performing very poor on a

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 all, Can i use The denoise preprocess in my pocketpc (ARM XSCALE 400 Mhz)? It seen there is no a fixed point version... Fabio <p><p>----- Original Message ----- From: "Jean-Marc Valin" <Jean-Marc.Valin@USherbrooke.ca> To: "speex" <speex-dev@xiph.org>; "Alex Wang" <alex@liveglobalbid.com> Sent: Friday, May 28, 2004 11:16 PM Subject:

Has anybody used anything other than a PC as a source for icecast2? Are PDAs powerfull enough? I know vorbis encoding takes a signifigant amount of CPU power, but I've been able to do it on 4 year old PCs. Does a 206MHz Intel StrongARM 32-bit RISC processor have as much power as a 200 Mhz Pentium? I'm thinking Compaq iPaq, running Familiar Linux and IceS, would make a nice portable

Hi all, I've got a 400MHz XScale-PXA255 board, and I want to stream voice from it over a network connection at 28.8baud. This calls for a capable voice encoder which can encode at about 24kbps. I was damn happy when I found Speex and said goodbye to MP3 :) However, i'm still a long way from realtime encoding using speexenc, is this possible? Using the fixed point math option in

Hello, I'm interested in a low rate vocoder to run on SA-1110 or XScale processor (for PDAs voice application). Is there a suitable speex vocoder for that? Thanks in advance, Eyal. ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag --- >8 ---- List archives:

Warning: newbie post I've scanned the archives and found some discussion of porting some code so it's integer based as opposed to floating point based. Has anyone looked at using Intel's Integrated Performance Primitives or their Math Kernel Library in an effort to optimize the code across all x86/XScale processors? IPP: http://www.intel.com/software/products/ipp/ipp30/ KML:

Hello, would it be possible to update config.sub and config.guess to the latest versions (or at least version from automake-1.13.1) in order to support new architectures based on the ARM 64 bit CPU? Patch: http://plautrba.fedorapeople.org/openssh/openssh-latest-config.sub-config.guess.patch Related Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=926284 Thanks, Petr

>What frequency is the ARM processor? The phone shows ARM720 no freq. I'm going to have to guess around 100 Mhz. I ran the same code on an XSCALE ARM 400 mhz. Toshiba e740. Runs about .33 -> .4x realtime. This is the using the generic fixed point defines. Around 5 times faster than I am seeing with the Orange SPV e100. I am using the 1.1.3 codebase. Thanks for taking the time to

Anyone have any idea if the any of the Sharc or TigerSHARC DSPs are powerful enough to do realtime Speex? <p>--- >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-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed.