Update to Speex

[Jean-Marc Valin]

Ron a écrit :
> On Mon, Mar 17, 2008 at 09:25:08PM +1100, Jean-Marc Valin wrote:
>> Ron a écrit :
>>> So if I've got this straight, the problem here is that we never should
>>> have distributed 1.1 at all in the first place, as it is not perfectly
>>> compatible with either 1.0 or 1.2 ?  (and you never claimed it would be)
>> Distributing 1.1.x was the right thing to do. Depending on the API/ABI
>> for the *new* stuff it included (noise suppression and AEC) was the
>> wrong thing to do. None of the apps that worked with 1.0.x broke with
>> 1.1.x or with 1.2.
> 
> hrm.  I think that changes the balance of things a little in my head ...

I don't understand what this changes. What did you originally think?

> Looking at what I have here, I see a couple of little changes that
> weren't forward compatible, the most immediately obvious being:
> 
>   -#define SPEEX_STEREO_STATE_INIT {1,.5,1,1}
>   +#define SPEEX_STEREO_STATE_INIT {1,.5,1,1,0,0}
> 
> The extra fields being zero might save a few cases, but mostly I'd
> expect this worked because no one is really using it yet ...
> Thats from 1.1.12 to 1.2beta2, so it may not have been a problem
> if we didn't count 1.1.x in the compatible release sequence.
> (or maybe I have it wrong and its not a problem, I didn't follow
> that deep)

The extra zeros just prevent something from being left uninitialised.
It's really a bugfix because the previous behaviour was leaving
undefined data (i.e. the user was lucky it worked). No API/ABI compat
issue. Note, this does *not* break API or ABI. It's just a bugfix.

> 
> The bigger issue though is that while adding all the extra code
> was forward compatible, removing it again is not ...

The added stuff was never *ever* marked as stable or anything like that.
The few who used it were often reminded of that fact.

> Separating the stable from the active code is definitely the right
> thing to do, but I'm not quite so sure if, having not done that
> right from the start (which would have been ideal) we should 'hide'
> the removal of these symbols from libspeex from the machine
> information in the library.
> 
> To people we can say "you shouldn't have used those symbols, it was
> even documented that you shouldn't rely on them", but for people who
> didn't read that either, the machine has no way of knowing they've
> made a mistake except when something fails catastrophically, shortly
> before they do.
> 
> Personally I think if it was my call, this would tip the scales toward
> using a technical solution.  The easy but blunt option is declare a
> new beginning, bump the libspeex soname to so.2, (and knock speexdsp
> back to so.0 if you like, from its current so.1, but probably better
> to just leave that at 1 as people are already using it too now).

Keep in mind that this solution breaks more stuff than it fixes. It
breaks all the code that was "well-behaved" by only depending on the
codec. On the other hand, for the stuff that depended on the unstable
features, the only difference is that they'd get an "undefined symbol"
at link instead of getting a "wrong library version". No big deal. It's
broken anyway.

> The best, but lots of hard work, option is to manage the symbol
> changes with elf linker tricks, but I suspect you don't want to
> melt your brain on that right now.

No. Plus it would force libspeex to know about libspeexdsp, which is bad.

> The messiest, but we can do it that way if we have to option,
> is to use the package dependency relationships to manually specify
> a conflict with every app that may have used the removed symbols.

What do you mean here?

> If the upgrade path was 1.0 -> 1.2beta3+, I think I'd agree not
> bumping the soname was best, but 1.1 -> 1.2beta2 have been in
> circulation for quite some time...  I'd wager a lot of people
> you've never heard of have code using the extra functions ...

Note that you've already broke the API/ABI several times, with each of
the 1.1.x releases you made (1.1.6 to 1.1.10 to 1.1.11, ...). I don't
understand why suddenly things are different.

> But that's more than enough from me on that, it's your call so
> we'll do whatever we have to from there.

I'd vote for stick with the same soname for libspeex, then do it right
for libspeexdsp.

>> Well, the resampler was broken in 1.2beta2 ...
> 
> hrm, its been working ok here, though my testing hasn't really
> exercised it very hard ...  I have a couple of other little things
> on a list I've been keeping for you, but I should check the newer
> code and get this thread out of the way first ;)

The resampler in beta2 was definitely broken, badly. It would produce
bad quality output in many cases and would crash in some corner cases.

> I guess with 20/20 hindsight libspeexdsp.so.0 might have been a better
> starting point, but the numbers themselves aren't particularly important
> so the law of least surprise would favour libspeexdsp1 for beta3.  The
> vast majority of users will expect libspeexdsp.so.1 to be provided by
> that, and a good number of them will get confused if its not.

The idea is that libspeexdsp.so.0 would be beta3 (or whatever). Then,
when 1.2 is released, we can have both libspeexdsp1 and libspeex1 to
make things less confusing.

> Sometime in the next couple of weeks would be nice.  The sooner the
> better, but not if it involves rushing something you'd rather do first.
> If its not really very different from beta3 I can get most of our side
> done with that and get the transition started, then we can bump that
> to beta4 when you have one ready.

The current code is not very different from beta3 actually. You could
pretty much ship it as a bugfix version of beta3... or wait for the next
release.

> Do you have a list of things in particular that need help right now?

Basically, the TODO list goes:
1) Lots of testing, especially for the new stuff
2) Documentation
3) Need to convert the AGC to fixed-point
4) Need to put back a decent VAD.

> I'm probably a few weeks away from really having my head in speexish
> things again (aside from beta3 packaging, and updating my code to
> suit), but I'll be happy to cherry pick anything I think I can along
> the way.  We can also call on the hordes to any degree that might be
> useful for particular problems ...

Good.

	Jean-Marc

> Cheers,
> Ron
> 
> 
> 
>