[Speex-dev] Speex with PS3 SPE support

[Joost Schuur]

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 at 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 at usherbrooke.ca] 
Sent: Thursday, October 25, 2007 4:36 PM
To: Joost Schuur
Cc: jim.crichton at 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 at 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 at 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 at usherbrooke.ca]
> Sent: Thursday, October 25, 2007 4:26 AM
> To: Joost Schuur
> Cc: Saad Nader; jim.crichton at comcast.net; speex-dev at 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 at 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 at usherbrooke.ca]
>> Sent: Wednesday, October 24, 2007 7:12 AM
>> To: Jim Crichton
>> Cc: Saad Nader; speex-dev at 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
>>
>>
> 
>