search for: xdais

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

...ething similar could be done to measure the peak stack usage, enabled by a debug switch. Then, for a space critical application, it would be easy to measure the stack requirement for a given operating mode, and set the size (manually) accordingly. >> Also, to nominally comply with the TI XDAIS algorithm standard, it is >> necessary to extract all of the memory allocation from the code, >> organize it into blocks, and provide a table to the application host >> with the size and scratch/persistent nature of each block. The host >> then does the memory allocating, a...

...aining 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 algorithm standard, it is > necessary to extract all of the memory allocation from the code, > organize it into blocks, and provide a table to the application host > with the size and scratch/persistent nature of each block. The host > then does the memory allocating, and provides the...

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

> > 4. I think the codec is portable to more fixed point embedded devices > > if you stick to C rather than C++ code. If you follow the TI XDAIS > > standard you'll wind up creating an object-oriented codec but you can > > do it all in C (Relocatable, re-entrant code, state structure, etc.). > > Who knows you might want to run it on an embedded DSP that doesn't > > support C++ someday. > > > I doubt...

...cent experience in both Speex and the TI DSP range while I do so. Then I'll enter into serious discussions about the fixed point version - see below. > 4. I think the codec is portable to more fixed point embedded devices > if you stick to C rather than C++ code. If you follow the TI XDAIS > standard you'll wind up creating an object-oriented codec but you can > do it all in C (Relocatable, re-entrant code, state structure, etc.). > Who knows you might want to run it on an embedded DSP that doesn't > support C++ someday. <p>I doubt I will. Others might...

...a memory usage, for applications running a > subset of the Speex coding modes. > The misc.c change allows private memory allocation, for cases where it is > not desirable to use the normal heap. > This makes it possible to sort of comply with the TI algorithm interface > standard (xDAIS). > > I changed my code today to follow the pattern used for the Sharc port > (OVERRIDE switches), but you might prefer a different style for including > the user-provided allocation routines. > > Regards, > > Jim Crichton -- Jean-Marc Valin <Jean-Marc.Valin@USherbr...

....c change reduces the data memory usage, for applications running a subset of the Speex coding modes. The misc.c change allows private memory allocation, for cases where it is not desirable to use the normal heap. This makes it possible to sort of comply with the TI algorithm interface standard (xDAIS). I changed my code today to follow the pattern used for the Sharc port (OVERRIDE switches), but you might prefer a different style for including the user-provided allocation routines. Regards, Jim Crichton -------------- next part -------------- A non-text attachment was scrubbed... Name: spe...

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

...ct integer implementation be formed? I would suggest that a fixed point model be formed on Linux, Cygwin and/or Windoze first. Then port to the 55x (see comment 4). 4. I think the codec is portable to more fixed point embedded devices if you stick to C rather than C++ code. If you follow the TI XDAIS standard you'll wind up creating an object-oriented codec but you can do it all in C (Relocatable, re-entrant code, state structure, etc.). Who knows you might want to run it on an embedded DSP that doesn't support C++ someday. 5. You should take a close look at the intrinsic definitions...

...the C55X. There should be a CCS download to fix this, although I haven't installed it myself. That is about all for now. Any comments or feedback are welcome as always. My personal goal at the moment is to get a fixed_point stable version for C55x so that I can then use that to develop an XDAIS algorithm, or some other TI DSP specific version which includes compiler specific settings so we get the best code size/MIPS ratio. Whether you'll want all that stuff put back into the main Speex release I don't know, but if you do that is fine with me too. Look forward to hearing from...