Joost Schuur wrote:> Saad has been keeping me in the loop on your recent discussions. > Since all of our testing has been against 1.0.5, based on that being the > last non-beta version, that's the particular scope of the task that Saad > is working on right now.I'm just saying it's useless to do any work on 1.0.5. It is inferior to the latest beta in all aspects, including code quality, performance, voice quality.> I like what I'm reading about as far as encoder/decoder quality > improvements e.g. in the 1.2 betas, and am going to push for testing for > compatibility against that here in the future, but it would help us if > you could comment on when you anticipate coming out with a non-beta > 1.2..Don't make a fixation on the beta thing. If I renamed the last beta to 1.2-final, what would it change to you? Also, because Speex is really small, it means I can make sure every release (including the ones labeled "unstable") have no known issues at the time of release. And if you look at the codec only (and not the extra DSP stuff I added in 1.1.x), none of the "unstable" releases has had any major bug. So please everyone stop making a fuss about version numbers, they're meaningless if you don't look at the actual piece of software. A beta release of Speex is far safer than the latest 2.6.x "stable" release of a Linux kernel, which is still safer than any "service pack" released by some large OS vendor. Jean-Marc> </j> > > Joost Schuur, Developer Support Manager, IGN Entertainment > jschuur@gamespy.com, tel: (714) 460-6728, cell: (949) 923 0074 > Publisher and Developer Services, http://www.poweredbygamespy.com > > NEW: Online Matters - PubServices blog: > http://www.poweredbygamespy.com/blog > > > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Wednesday, October 24, 2007 7:12 AM > To: Jim Crichton > Cc: Saad Nader; speex-dev@xiph.org > Subject: Re: [Speex-dev] Speex with PS3 SPE support > > 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 > >
Joost Schuur wrote:> My primary concern is the use of the word 'unstable' on the current > download page for 1.2b2. One of our major devloper partners in > particular saw that reference and opted to use 1.0.5 on their PS3 title, > which is why we based our work for them on 1.0.5. The kind of commercial > game developers that are our customers aren't going to have the benefit > of the insight into the current status of the code that you have, so > they have to make judgement calls based on how the code version is > labelled."Unstable" basically means "unstable API" and that refers mainly to the new dsp functions (which weren't in 1.0.x" and the few things I added to the codec still need to stabilise a bit (everything that was in 1.0.x is still working fine).> Renaming it to 1.2 final, without the unstable moniker would > definitely help reassure this one developer in particular, and would > have meant they would have happily used 1.2 instead. Is there another > release planned in the near future? Or would you consider renaming the > current beta, as suggested?You know, there are Firefox extensions that can replace words you don't like on a page (just like they replace ads). There is a beta3 planned soon, probably followed by RCs. No, I am *not* renaming to 1.2 because some people don't like to see "unstable". However, I'll gladly send you a script that can do it on your own version. However, the mainline will only be marked "stable" once I can say that I'm not going to change details in the API.> PS: I wasn't sure what the scope of the speex-dev@xiph.org list was, so > I left it off of this thread for now.Pretty much anything about Speex is on-topic for the list. CCing the list again. Jean-Marc> Joost Schuur, Developer Support Manager, IGN Entertainment > jschuur@gamespy.com, tel: (714) 460-6728, cell: (949) 923 0074 > Publisher and Developer Services, http://www.poweredbygamespy.com > > NEW: Online Matters - PubServices blog: > http://www.poweredbygamespy.com/blog > > > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Thursday, October 25, 2007 4:26 AM > To: Joost Schuur > Cc: Saad Nader; jim.crichton@comcast.net; speex-dev@xiph.org > Subject: Re: [Speex-dev] Speex with PS3 SPE support > > Joost Schuur wrote: >> Saad has been keeping me in the loop on your recent discussions. >> Since all of our testing has been against 1.0.5, based on that being >> the last non-beta version, that's the particular scope of the task >> that Saad is working on right now. > > I'm just saying it's useless to do any work on 1.0.5. It is inferior to > the latest beta in all aspects, including code quality, performance, > voice quality. > >> I like what I'm reading about as far as encoder/decoder quality >> improvements e.g. in the 1.2 betas, and am going to push for testing >> for compatibility against that here in the future, but it would help >> us if you could comment on when you anticipate coming out with a >> non-beta 1.2.. > > Don't make a fixation on the beta thing. If I renamed the last beta to > 1.2-final, what would it change to you? Also, because Speex is really > small, it means I can make sure every release (including the ones > labeled "unstable") have no known issues at the time of release. And if > you look at the codec only (and not the extra DSP stuff I added in > 1.1.x), none of the "unstable" releases has had any major bug. > > So please everyone stop making a fuss about version numbers, they're > meaningless if you don't look at the actual piece of software. A beta > release of Speex is far safer than the latest 2.6.x "stable" release of > a Linux kernel, which is still safer than any "service pack" released by > some large OS vendor. > > Jean-Marc > >> </j> >> >> Joost Schuur, Developer Support Manager, IGN Entertainment >> jschuur@gamespy.com, tel: (714) 460-6728, cell: (949) 923 0074 >> Publisher and Developer Services, http://www.poweredbygamespy.com >> >> NEW: Online Matters - PubServices blog: >> http://www.poweredbygamespy.com/blog >> >> >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] >> Sent: Wednesday, October 24, 2007 7:12 AM >> To: Jim Crichton >> Cc: Saad Nader; speex-dev@xiph.org >> Subject: Re: [Speex-dev] Speex with PS3 SPE support >> >> 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 >> >> > >
Hi, On 10/26/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote:> Joost Schuur wrote: > > My primary concern is the use of the word 'unstable' on the current > > download page for 1.2b2. One of our major devloper partners in > > particular saw that reference and opted to use 1.0.5 on their PS3 title, > > which is why we based our work for them on 1.0.5. The kind of commercial > > game developers that are our customers aren't going to have the benefit > > of the insight into the current status of the code that you have, so > > they have to make judgement calls based on how the code version is > > labelled. > > "Unstable" basically means "unstable API" and that refers mainly to the > new dsp functions (which weren't in 1.0.x" and the few things I added to > the codec still need to stabilise a bit (everything that was in 1.0.x is > still working fine). > > > Renaming it to 1.2 final, without the unstable moniker would > > definitely help reassure this one developer in particular, and would > > have meant they would have happily used 1.2 instead. Is there another > > release planned in the near future? Or would you consider renaming the > > current beta, as suggested? > > You know, there are Firefox extensions that can replace words you don't > like on a page (just like they replace ads). There is a beta3 planned > soon, probably followed by RCs. No, I am *not* renaming to 1.2 because > some people don't like to see "unstable". However, I'll gladly send you > a script that can do it on your own version. However, the mainline will > only be marked "stable" once I can say that I'm not going to change > details in the API.After split of codec and DSP stuff is done - probably it make sense to give codec part "stable" label, while maintaining DSP part as unstable? I think this will make things much clearer then they are now without many words being said. :) Well, it's a generic question, interesting to all Speex users, after all - do you want to maintain versions of codec and dsp parts separately or in conjunction? -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
Hi Jean-Marc, Jim, Saad has been keeping me in the loop on your recent discussions. Since all of our testing has been against 1.0.5, based on that being the last non-beta version, that's the particular scope of the task that Saad is working on right now. I like what I'm reading about as far as encoder/decoder quality improvements e.g. in the 1.2 betas, and am going to push for testing for compatibility against that here in the future, but it would help us if you could comment on when you anticipate coming out with a non-beta 1.2.. </j> Joost Schuur, Developer Support Manager, IGN Entertainment jschuur@gamespy.com, tel: (714) 460-6728, cell: (949) 923 0074 Publisher and Developer Services, http://www.poweredbygamespy.com NEW: Online Matters - PubServices blog: http://www.poweredbygamespy.com/blog -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Wednesday, October 24, 2007 7:12 AM To: Jim Crichton Cc: Saad Nader; speex-dev@xiph.org Subject: Re: [Speex-dev] Speex with PS3 SPE support 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
What it boils down to is that it's outside of our control, what version of the code a customers of ours will pick and our current work had to be done based on their selection. I can merely provide you with the feedback, that a major game developer, for a AAA title opted not to use 1.2, due to the word unstable used in the description. Take that as you may. We're still happy to adapt our updates to 1.2 as soon as it can be scheduled here. We'll let you know once that's the case. </j> Joost Schuur, Developer Support Manager, IGN Entertainment jschuur@gamespy.com, tel: (714) 460-6728, cell: (949) 923 0074 Publisher and Developer Services, http://www.poweredbygamespy.com NEW: Online Matters - PubServices blog: http://www.poweredbygamespy.com/blog -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Thursday, October 25, 2007 4:36 PM To: Joost Schuur Cc: jim.crichton@comcast.net; Saad Nader; speex mailing list Subject: Re: [Speex-dev] Speex with PS3 SPE support Joost Schuur wrote:> My primary concern is the use of the word 'unstable' on the current> download page for 1.2b2. One of our major devloper partners in > particular saw that reference and opted to use 1.0.5 on their PS3 > title, which is why we based our work for them on 1.0.5. The kind of > commercial game developers that are our customers aren't going to have> the benefit of the insight into the current status of the code that > you have, so they have to make judgement calls based on how the code > version is labelled."Unstable" basically means "unstable API" and that refers mainly to the new dsp functions (which weren't in 1.0.x" and the few things I added to the codec still need to stabilise a bit (everything that was in 1.0.x is still working fine).> Renaming it to 1.2 final, without the unstable moniker would > definitely help reassure this one developer in particular, and would > have meant they would have happily used 1.2 instead. Is there another > release planned in the near future? Or would you consider renaming the> current beta, as suggested?You know, there are Firefox extensions that can replace words you don't like on a page (just like they replace ads). There is a beta3 planned soon, probably followed by RCs. No, I am *not* renaming to 1.2 because some people don't like to see "unstable". However, I'll gladly send you a script that can do it on your own version. However, the mainline will only be marked "stable" once I can say that I'm not going to change details in the API.> PS: I wasn't sure what the scope of the speex-dev@xiph.org list was, > so I left it off of this thread for now.Pretty much anything about Speex is on-topic for the list. CCing the list again. Jean-Marc> Joost Schuur, Developer Support Manager, IGN Entertainment > jschuur@gamespy.com, tel: (714) 460-6728, cell: (949) 923 0074 > Publisher and Developer Services, http://www.poweredbygamespy.com > > NEW: Online Matters - PubServices blog: > http://www.poweredbygamespy.com/blog > > > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Thursday, October 25, 2007 4:26 AM > To: Joost Schuur > Cc: Saad Nader; jim.crichton@comcast.net; speex-dev@xiph.org > Subject: Re: [Speex-dev] Speex with PS3 SPE support > > Joost Schuur wrote: >> Saad has been keeping me in the loop on your recent discussions. >> Since all of our testing has been against 1.0.5, based on that being >> the last non-beta version, that's the particular scope of the task >> that Saad is working on right now. > > I'm just saying it's useless to do any work on 1.0.5. It is inferior > to the latest beta in all aspects, including code quality, > performance, voice quality. > >> I like what I'm reading about as far as encoder/decoder quality >> improvements e.g. in the 1.2 betas, and am going to push for testing >> for compatibility against that here in the future, but it would help >> us if you could comment on when you anticipate coming out with a >> non-beta 1.2.. > > Don't make a fixation on the beta thing. If I renamed the last beta to> 1.2-final, what would it change to you? Also, because Speex is really > small, it means I can make sure every release (including the ones > labeled "unstable") have no known issues at the time of release. And > if you look at the codec only (and not the extra DSP stuff I added in > 1.1.x), none of the "unstable" releases has had any major bug. > > So please everyone stop making a fuss about version numbers, they're > meaningless if you don't look at the actual piece of software. A beta > release of Speex is far safer than the latest 2.6.x "stable" release > of a Linux kernel, which is still safer than any "service pack" > released by some large OS vendor. > > Jean-Marc > >> </j> >> >> Joost Schuur, Developer Support Manager, IGN Entertainment >> jschuur@gamespy.com, tel: (714) 460-6728, cell: (949) 923 0074 >> Publisher and Developer Services, http://www.poweredbygamespy.com >> >> NEW: Online Matters - PubServices blog: >> http://www.poweredbygamespy.com/blog >> >> >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] >> Sent: Wednesday, October 24, 2007 7:12 AM >> To: Jim Crichton >> Cc: Saad Nader; speex-dev@xiph.org >> Subject: Re: [Speex-dev] Speex with PS3 SPE support >> >> 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 >> >> > >