Update to Speex

[Jean-Marc Valin]

Ron a écrit :
> Hi Jean-Marc,
> 
> Thanks for your input on this, I'd like to try and figure out two things
> as quickly as we can:  where have things got screwed up, and what do we
> need to do to fix them ...
> 
> Once we're all on the same page about that, what to do about it should
> be fairly self-evident I hope.  So I have a couple of extra questions:
> 
> 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.

> It's more likely that nobody noticed.  That doesn't make the problem
> less real when someone does bump into it though.  Since we don't all
> yet see a solution we agree upon, presumably we aren't all seeing the
> problem clearly yet either.  Please correct anything that follows which
> is wrong:
> 
>  The 1.0 release and libspeex from 1.2beta3 are perfectly compatible.
>  Any possible app built with 1.0 can use 1.2 without a rebuild.

Correct. BTW, any possible app built with 1.0 can *also* use 1.1 without
rebuild.

>  The bits of libspeex that have been changing since 1.1 are now all
>  in libspeexdsp

Correct. Just to be more precise, it's the stuff that got *added* in 1.1
that is now in libspeexdsp because none of the 1.0.x stuff ever changed.

>  Neither libspeex nor libspeexdsp depends on the other.  Each could
>  be used alone by some application.

Correct.

>  You consider the libspeex API frozen at revision 1.  You reserve
>  the right to make further changes to libspeexdsp as required still.

Correct. I might change libspeexdsp, though it will (of course) be
frozen for 1.2. My plan is that 1.2rc1 will be a "soft freeze" (won't
change unless something major comes up) for the libspeexdsp API.

> If all that is true, then it sounds like we should ship libspeex.so.1
> from 1.2beta4, and split libspeexdsp into at least its own binary .deb
> if not its own source package.

It definitely makes sense to ship libspeexdsp in a separate binary
package. However, there are many header files in common, so splitting
the source package would be complicated. Even for the development
package, it might be a good idea to make the libspeexdsp-dev depend on
libspeex-dev as there are two header files (basic type definitions) in
common. The dev package dependency would be avoidable though.

> The remaining problem in that scenario is that the libspeexdsp soname
> currently appears bound to the one used by libspeex.  If we are to
> also distribute libspeexdsp (which I would personally like us to),
> then the workflow for releases would mean bumping the soname for
> libspeexdsp at every public release where its A{P,B}I changes
> incompatibly.  That doesn't seem unreasonable, that is precisely
> what the soname is for -- but we don't have to get libspeex caught
> up in a bump because of it.  Only the people using speexdsp have
> to chase the changes, and they made that choice for themselves.

Sounds reasonable. I would suggest calling the package libspeexdsp0 or
something until the API/ABI is stable.

> What is important is that you accurately reflect which bits change,
> and we accurately pass that information along to the users.  If we
> can put a peg in the sand here, and agree on how and when to do
> that in the future, it should all be smooth sailing ;)

I think we mostly agree so far.

>> I'm not going to break the ABI for libspeex, only for libspeexdsp.
> 
> Separating their soname changes is logical then.

Agreed

> I've been using the resampler and the preprocessor from 1.2beta2.
> Splitting that out is an incompatible change to libspeex from that
> release, but we can probably pretend that never happened too if it
> will be handled right from here onward.

Well, the resampler was broken in 1.2beta2 and I think most apps that
needed the noise suppressor and AEC were shipping with their own version
of Speex.

> If Ekiga/Mumble/etc want to be part of a release, they'll just have
> to be compatible with libspeexdspN for whatever N is the release
> you recommend we ship in distro snapshots.  So long as you increase
> N when you make an incompatible release, all will work as it should.

Where N is the soname or the package name suffix? I'd suggest just
calling the package libspeexdsp0 (no matter what the soname is). BTW,
I'm *expecting* the next API/ABI to be the final one. It's not like
there'll be 10 more changes.

> Or we need to package an svn snapshot.  But if you are happy enough with
> the current code to at least make a beta4 snapshot, that seems like a
> fairly easy better solution all round.

I'll think about it. When do you need an answer? (and a release?)

> If you are happy to bump the speexdsp soname (if needed) when you make
> a release you would like us to ship, we can separate these two tracks
> of development similarly.

Agreed.

>> Can you please take what Debian has in unstable and release as Lenny.
>> Then you can just resume work on the next release?
> 
> We can't quite do that, there are a few things in that which need to
> be tidied, as well as updating it to beta3+ with libspeexdsp split out.

No that was just a joke. As if Debian would just release lenny tomorrow
based on what they had.

> You can find the current schedule here:
> http://release.debian.org/emails/release-update-200801
> 
> Looks like mid june is the projected hard cutoff for libspeex
> releases.  So we need to have all the teething problems and app
> transitions over by then.  Parts of the distro are already being
> cooled, so we really want to have this transition well on its
> way or 'finished' by april if possible.  Apps will still need
> time for any issues to shake out with use.

My hope was actually go have the API/ABI frozen by june, so it's
realistic. BTW, any help on this would be appreciated :-)

	Jean-Marc