Please correct me if I am wrong, Jean-Marc, but I do not think that any patches are getting applied to 1.0.5 anyway. Also, if you expect a patch to be applied, you will need to provide the changes as a patch, not as a modified copy of the source tree. The 1.2 branch includes a mechanism for private memory allocation from a static buffer. You provide a usermisc.h file that replaces the normal alloc routines. You should be able to fix most if not all of your alignment issues there, rather than putting conditionals in the main code. I do not know if it will allow you to avoid the __attribute__ directives. Look at the TI subdirectory in the main tree for an example of how this is done. There is a bit of a hack for providing a private stack without changing the API. I do not think that there is any precedent for platform specific API changes, such as what you have proposed. It will take some work to move to the 1.2 branch, but with it comes two years of improvements in quality and processing and memory efficiency. Regards, Jim Crichton ----- Original Message ----- From: "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca> To: "Saad Nader" <snader@gamespy.com> Cc: <speex-dev@xiph.org> Sent: Tuesday, October 23, 2007 7:20 PM Subject: Re: [Speex-dev] Speex with PS3 SPE support> Saad Nader wrote: >> We needed to use a release version of the SDK because this part of >> production code for our Sony implementations. I'm not sure how stable >> that branch is. Is the encoding and decoding already stable? In other >> words, what is not stable about that branch? > > It's listed as "unstable" in the sense of "I might change the API" and > that is mainly for new features that are not related to the codec itself > (echo cancellation, ...). Also, because I do more changes, the > likelyhood of breaking things is slightly higher. That being said, the > overall quality (and even "stability" in the sense of how much I trust > the code) is much higher in the latest 1.2beta releases than for the > 1.0.x branch. > > Jean-Marc > >> Thanks, >> --------------------------- >> Saad Nader >> Middleware Engineer >> Powered By Gamespy, IGN >> >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] >> Sent: Tuesday, October 23, 2007 1:53 AM >> To: Saad Nader >> Cc: speex-dev@xiph.org >> Subject: Re: [Speex-dev] Speex with PS3 SPE support >> >> Hi Saad, >> >> I noticed you've been using 1.0.5. This is actually quite old. There are >> many many improvements and optimisations in the unstable branch >> (1.2beta2 is the latest) and you should definitely be using that on the >> Cell. >> >> Cheers, >> >> Jean-Marc >> >> > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev >
Hi Jim, Jim Crichton wrote:> Please correct me if I am wrong, Jean-Marc, but I do not think that > any patches are getting applied to 1.0.5 anyway. Also, if you expect > a patch to be applied, you will need to provide the changes as a > patch, not as a modified copy of the source tree.That's right. I won't be applying anything 1.0.5 unless it's a security issue or something like that.> The 1.2 branch includes a mechanism for private memory allocation > from a static buffer. You provide a usermisc.h file that replaces > the normal alloc routines. You should be able to fix most if not all > of your alignment issues there, rather than putting conditionals in > the main code. I do not know if it will allow you to avoid the > __attribute__ directives. Look at the TI subdirectory in the main > tree for an example of how this is done. There is a bit of a hack for > providing a private stack without changing the API. I do not think > that there is any precedent for platform specific API changes, such > as what you have proposed.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 less messy than misc.h/misc.c were. Cheers, Jean-Marc
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 > less messy than misc.h/misc.c were.The TI C64x build produces bit-exact results with build 12825 (April 2007, a bit before 1.2beta2). The C54x and C55x builds did not work because the manual allocation scheme was broken when misc.c was removed. The old override mechanism was: 1. Define USER_MISC in config.h 2. In, misc.c, include user_misc.h if USER_MISC is defined 3. Put the allocation override code in user_misc.h. The result is that the override code is included in one source file (misc.c), so there are no duplicate definitions. How would you like to see this implemented under the current structure? Including the override functions in os_support.h does not work unless the overrides are also static inlines (otherwise duplicate definitions occur). For code size efficiency, it would be nice if these functions were not required to be static inline. The function prototypes were removed from misc.h, so now they are defined nowhere when overrides are defined. There is no way around that without some change to the source. What do you think? - Jim