similar to: some questions about speex on TMS and also unsubscribe

dear sir/madam, i am runnin the speex codes for the TI-DSP in CCS. i have also given the same input file that has been mentioned in the readme-TIDSP. the code runs perfectly ( i think) but it takes a lot of time for the *.out file to "run". the output file, which is supposed to be "maleout5x" has a size much bigger than the input file "male.snd" (the input file is

Hi, I can see that there has been some effort to compile the SPEEX codec to operate on the TI c54x and c55x DSPs and I am wondering if anyone would be able to update the mailing list with their current MIPs and Memory resource requirements for their c54x and/or c55x compilation? The only estimate I was able to find in the mailing list archive was 42MIPs but I'm not sure if this is an

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

It would be great to get some idea of what chips and DSPs people have tried to compile Speex for, and what success they've had. So, if you've tried Speex on a chip, could you take a second to fill in the following and post it to the list? Chip Name: Speex Version: Floating or Fixed: Encode, Decode, Both or Simultaneous: MIPS (if known): Other comments: Many thanks, Gerv

Jean-Marc Valin wrote: > I don't know all the details, but here's a (partial) list of archs on > which I've heard of Speex running. I'm sure there are others (especially > the float version should really run on any chip with an FPU). > > float: > x86/x86-64 (SSE assembly optimizations provided) > PowerPC > SPARC I've had floating decoding running on a

Hi Jim, > Build 11169 in SVN works correctly. Good. I'll try not to forget the EXTEND32 from now on. > I have attached a zip file (renamed > .txt) with a patch to bits.c to make the byteswapping for TI DSPs > consistent. Seems like unzip can't read it. Either it's in an unknown format or the file got corrupted. Could simply send as multiple (uncompressed)

>> Nice call. The culprit is SHRL32. This is not used in many places, and >> in >> most of those, the operand comes from EXTEND32. The only really >> suspicious >> instances is in lsp.c (lsp_interpolate): >> >> spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); >> (subframe is an int) >> ... >> I see that your

> You found it. The SHL32 (not SHR32) line fixes the problem. It must be > doing a 16-bit shift, then extending the result (which is reasonable). As > it happens, that it the same macro which gave us trouble last May > (25th/26th), when the C55 build was more subtlely broken. Yes, that's what I finally remembered. I think I've fixed all occurrences (by adding EXTEND32)

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: maleout12may.wav Type: audio/wav Size: 95884 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20050524/57112d0c/maleout12may-0001.bin

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

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

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

> The C5x and C6x output diverges in build 10143, which has log message "lpc > floor converted to fixed-point." Also, the measured SNR changed from 11.05 > in builds 9854-10141 to 9.22 and 9.24 in 10143. Actually, build 10143 introduced another bug, that was the reason for the 1.1.11.1 release. > There is just four lines in modes.c which declare the constant, and one

Hi everyone, I've recently done some major internal changes in Speex aimed at reducing RAM (by nearly a factor of 2!) and improving quality of the fixed-point. In doing so, I might have accidently broken a few things. I'd like to hear feedback on the current svn code to make sure I fix any regression before the next release. I'm already aware that --enable-vorbis-psy is broken and

Stuart, Jean-Marc, >> 1) We need our own "fixed_xx.h" header file. I don't know why, and >> haven't >> had time to investigate, but there is a definite improvement when I use >> the >> attached fixed_c55x.h file which has turned all the maths into inline >> functions. > > Did you try with fixed_generic.h or just with fixed_debug.h?

Jean-Marc, Attached is a patch (to build 14264) to fix the TI DSP builds with the recent restructuring of libspeex. The change adds a hook in os_support.h to allow the user to override some memory allocation and I/O functions. A similar hook was present in misc.c, but was lost when that file was removed. Also, the size of the private memory allocation area has been reduced, to match

Jean-Marc, > That reminds me that I've just moved lots of stuff around with the > allocation functions. Can you check that the TI stuff still works with > that? In the end, it'll probably make things easier for you now. For > example, if you link statically, wideband should be automatically left > out if unused. Also, all the libc stuff is now in os_support.h, which is >

Hello, I currently have speex "working" in my project but the encode and the decode don't seem to be working like I would hope. I am using speex 1.2beta2 and I am trying to 16bit 8kbs narrowband. on the decode side I encoded a voice on a windows machine. I took the encoded information and transferred it over to the C54x project and decoded it and it didn't sound that great.

Jean-Marc, >> > It's odd that it "almost" works with the fixed_generic.h. The easiest >> > thing would be to gradually replace routines and see which one causes >> > problem. It's most likely (though I'm not 100% sure) that somewhere in >> > the code, I have a 16-bit value that gets sent to a function/macro that >> > expects a

hi, am trying speex on TI c54x dsp. does anyone has any idea whether we can make both the coder AND decoder run in about 10ms for a 20ms frame for this dsp, looking at narrowband, no VAD/CNG/VBR, using a low complexity, say 1, for a midrange bitrate, say 15kbps? was the c55 dsp able to run real-time on speex for the above configuration? can someone share their timings? tia! oh yes, just