similar to: [LLVMdev] DSP backends

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.

They claim to max out at 1,800 MFLOPs And have a clock speed of up to 300 mhz. Jean-Marc Valin wrote: >Tell me how fast these chips are, I'll tell you if there's a chance... > > Jean-Marc > >Le jeu 18/12/2003 à 16:52, David Siebert a écrit : > > >>Anyone have any idea if the any of the Sharc or TigerSHARC DSPs are >>powerful enough to do realtime Speex?

For some reason I'm getting Access denied errors when I try to execute a .bat file that resides on a TRU64 samba share, from a Win95 command prompt. The drive is mapped as x:\ & for the sake of testing, the directory has been recursively set to 777 (chmod). Command prompt output: x:\> x:\r235\src\ntprpst\sharc\mta\src\build_sharc_fta.bat Access denied -

For some reason I'm getting Access denied errors when I try to execute a .bat file that resides on a samba share (from a Win95 command prompt). The drive is mapped as x:\ & for the sake of testing, the directory has been recursively set to 777 (chmod). Command prompt output: x:\> x:\r235\src\ntprpst\sharc\mta\src\build_sharc_fta.bat Access denied -

Le ven 19/12/2003 à 09:38, David Siebert a écrit : > They claim to max out at 1,800 MFLOPs > And have a clock speed of up to 300 mhz. Are you kidding? Not only is this enough to encode/decode in real-time, but you can probably do ~50 channels (or more) at the the same time. Jean-Marc > Jean-Marc Valin wrote: > > >Tell me how fast these chips are, I'll tell you if

Hi, Just a couple tips to reduce complexity. First, I think you'd get a good speedup by enabling the PRECISION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already

Now that everything seems to rock I've hit the next hurdle. In my extensions.conf I have the extension: [agi-async] exten => _01XXXX,1,Agi(agi:async) and I can see that the context is "hit" when dialing into *. However my java app that's supposed to receive async agi events get no such events at all, but it does receive other manager API events. * version is 1.6.1.4

I'm converting Ubuntu startup scripts to work on CentOS (5.3), and I'm having trouble finding out how to start a daemon in a certain directory? For Ubuntu, start-stop-daemon has the option -d to set the working directory. TIA /Rob

Hi Jim, Thank for the patch. I'll apply it when I have a few minutes. If I haven't done so after a few weeks, please send it again. I'm in the process of relocating to Australia, so everything's a bit of a mess around here. Also, please post the c5X-specific files to the list (.cmd, .pjt, ...) so they'll be archived. Last thing, I see you defined spx_word64_t as long long for

Jean-Marc, I have attached a small patch with modifications to arch.h, bits.c, and misc.c. This contains the few mods remaining to support the various fixed point TI DSPs after the work that you did at the end of May (thank you for this). arch.h: Add switch for compilers not supporting "long long" (C55x does, C54x and older C64x does not) bits.c: Allow external definition for max

> 3. I'm interested in the methodology for creating a fixed point > implementation and guaging how "good" it is relative to the floating > point golden standard My methodology at this stage is to get it working on the floating point DSP first and to gain recent experience in both Speex and the TI DSP range while I do so. Then I'll enter into serious discussions about

The attached file contains build files for TI's Code Composer Studio (CCS) for the C54x, C55x, and C6x DSPs. I had intended to post this a couple of months ago, but it took a long time to get around to doing the little bit of cleanup required. This is a file I/O loopback application suitable for running with the CCS simulators, for evaluating memory and MIPs requirements for these

Hi all, I've setup two * servers which are SIP interconnected ala osaka/toronto from the * book (before anyone sugggests using IAX instead, no, I NEED to have them SIP interconnected for verification/test purposes). Then I have a Zoiper connected to one of them via IAX (so that * will not reinvite (?)). As soon as I try to call (via Zoiper) an extension on the other * I get a "Failed to

I've been following this kist for a while now and I suppose I had better introduce myself. This is going to be rather a long message, but that can't be avoided. My name is Andrew Baker and I work for a company called TeleDesign. We are based in the UK. http//www.teledesign.co.uk I have lots of experience with telecomms, a fair bit with VoIP, quite a bit (but rather less recent) with

On Aug 9, 2013, at 2:16 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > For our back end, we absolutely do not want a type system without pointers - not only do we have separate registers for pointers, we also have separate instructions for manipulating them and representing this in SelectionDAG requires some very ugly hacks. This is also the case for several DSPs, which

Let me chime in with a few facts regarding DSPs. It may be review to anyone who has programmed DSPs, but some may find it informative. Fixed-Point vs. Floating Point DSP chips Floating Point DSPs make the best/easiest compiler targets. Most of the standard operations present in ANSI C translate fairly well into floating point DSP assembly. This reduces the need for assembly

> >I fixed it in svn. Could you check that? > > Now all platforms match again. Note that the measured SNR for this test > sample is lower than with the broken code (10.87 vs 11.10), but of course > this is no way to judge the real quality. SNR, especially on a single sample, can be very misleading. Yet, could you just check that the DSP results match what you get on a PC?

We are bellow 30MIPS for our 16bit single MAC fixed point DSP. 8khz/8kbps I aggree with Jean-Marc that MIPS is dependent from the target DSP, but it's a very good indication when you compare same architecture DSPs. It is very difficult (impossible) to use effecient a DSP using only c. George ----- Original Message ----- From: "Andre Borrelly" <andre@myavalaunch.com> To:

On 9 Aug 2013, at 00:18, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I am hoping that this proposal will generate a lot of feedback, and there are many different topics to discuss. When replying to this email, please change the subject header to something more specific, but keep the [global-isel] tag. Subject changed, but I'm not sure if helps... Overall, I really like this

llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations. However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access. I have already read this mail thread: