similar to: Speex 1.0.5 and 1.1.8 are out!

Hi everyone, As many noticed, I just released 1.0.5 and 1.1.8 over the weekend. There isn't much new in 1.0.5, except that I added all the API changes from 1.1.x so that it's possible to write code that will work with both 1.0.5 and 1.1.8. As for 1.1.8, here are the changes: - Initial TI C5x port: I integrated a patch from Jamey Hicks - Some fixed-point improvements and fixes - Better

Hi Jim, Thanks a lot for helping track problems with Speex. > There is a bit of work remaining to get the memory usage down for a > multichannel application. There have been some good posts over the > last couple of months about reducing memory usage. I think 1.1.8 incorporates all memory reductions proposed. Let me know otherwise. > Also, to nominally comply with the TI XDAIS

Jamey, There is a previous posting in the speex archives with a link to the dsp c5x patch. Archive link: http://lists.xiph.org/pipermail/speex-dev/2004-October/002847.html Patch link: http://lists.xiph.org/pipermail/speex-dev/attachments/20041029/facb8c73/spee x-1.1.6-jeh1-0001.bin But that patch is very different (much smaller) then the dsp c5x patch at

Hi Jamey, Really cool to see Speex being ported to the C55xx and I'd be glad to integrate the changes required in Speex (and the style's fine with me). Here are a couple comments on the patch you sent (I looked at it, but haven't compiled). 1) The changes you made to the pack un unpack functions would only work if the 16-bit chars are "big endian" (relative to the two bytes

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

Greetings, I've just started porting speex to a TI C5509 DSP. It doesn't look like it's going to be too painful, but there are a couple of quirks about the C5x. 1) chars are 16 bits because memory addresses are for 16bit words 2) ints and short are also 16 bits (so sizeof(char) = sizeof(short) = sizeof(int) = 1) 3) the c5x is essentially big endian My plan is to change int and

>> There is a bit of work remaining to get the memory usage down for a >> multichannel application. There have been some good posts over the >> last couple of months about reducing memory usage. > > I think 1.1.8 incorporates all memory reductions proposed. Let me know > otherwise. For the persistent storage, the only change that I have made is to MAX_CHARS_PER_FRAME,

> For the persistent storage, the only change that I have made is to > MAX_CHARS_PER_FRAME, which is set to 2000 in bits.c. I changed bits.c to > set this value only if it was not already defined, and then put my own, much > smaller value in config.h. Yeah, I think I'll add an option like that. > For the scratch stack, I replace the fixed values in nb_encoder_init 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?

> I incorporated Stuarts fixed_c55x.h file, and that eliminated the artifacts, > at the expense of a ~30% increase in MIPs. Now the male.wav file through > encoder/decoder produces a bit-exact match with the C64x test that I did > earlier. I will do some more testing to isolate the, but it may be a few > days before I get to this task. As Jean-Marc says, fixed_generic should

Jean-Marc, >> I incorporated Stuarts fixed_c55x.h file, and that eliminated the >> artifacts, >> at the expense of a ~30% increase in MIPs. Now the male.wav file through >> encoder/decoder produces a bit-exact match with the C64x test that I did >> earlier. I will do some more testing to isolate the, but it may be a few >> days before I get to this task. As

Hi Alfred, First thing I'd like to ask is whether you're trying to achieve real-time performance, as I find it very unlikely that Speex could run in real-time on a micro-controller. Regarding bufSize, no you can't just make it the size you like. Now, it's possible to decrease the amount of memory allocated if e.g. you only use complexity 1. You can also assume that the stack is

Hi, I saw there is a new release of speex. What is this SPEEX_PLC_TUNING option for? And is there a more complete list of changes? Because I like to determine if it is interesting to update to 1.1.8 Greetings Jeroen de Kleijn (developer of VoIPerized)

Hi I am currently trying to port speex v1.1.6 to a microcontroller with very limited memory (<64Kbyte RAM). what I found when initialising the encoder, a chunk of 32Kb was attempted to be alloced, which failed: src/nb_celp.c: void *nb_encoder_init(const SpeexMode *m) { /* snip */ st = (EncState*)speex_alloc(sizeof(EncState)+8000*sizeof(spx_sig_t)); /* snip */ } same goes for the

Sorry for the delay. On 4/13/09, Alfred E. Heggestad <aeh at db.org> wrote: > Ivo, could you also review the updated memo-status/copyright notice, > located on page 1-2 ? Is this a new standard for writing Internet drafts? I've never seen it in other documents. Specifically, this part: "This document may not be modified, and derivative works of it may not be created,

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 there is a small bug in the sample code 'sampledec.c' here: http://www.speex.org/manual2/node12.html#SECTION000121000000000000000 it is trying to destroy the encoder of the "decoder" state, this patch should fix it: Index: doc/sampledec.c =================================================================== --- doc/sampledec.c (revision 11555) +++ doc/sampledec.c

Alfred E. Heggestad wrote: > <...> > > If we don't get any comments in 1 week (by 22. May 2007) we will go ahead > and submit it to the IETF. Of course you can comment on it also after it > has been submitted, but we would like to get the input from the Speex > community first.. > thanks for all the input. please find attached an updated version of the draft. I

Jean-Marc Valin wrote: >Hi Jamey, > >Really cool to see Speex being ported to the C55xx and I'd be glad to >integrate the changes required in Speex (and the style's fine with me). >Here are a couple comments on the patch you sent (I looked at it, but >haven't compiled). > > > Cool. >1) The changes you made to the pack un unpack functions would only

I saw a thread in the list archives about a speex port to TI 55x DSP. Wondering how that worked out (is working out)? Also wondering if there is a source archive for it, or if the patch in the email archives is still current, or if there's been updates. Any info appreciated. Thanks Paul