Update to Speex

[Ron]

On Wed, Mar 19, 2008 at 08:26:11AM +1100, Jean-Marc Valin wrote:
> > As I understand it now though, the promise was a bit more complex.
> > You were promising libspeex 1.1+ as better and compatible, but there
> > were extra bits included in it, where all bets were still off as to
> > what might have to change in them.
> 
> More or less correct. Considering that I broke the "new stuff" so many
> times in 1.1.x, nobody could ever have assumed it was supposed to be
> stable. Plus, if you look at all the versions debian included in 1.1.x,
> you'll see that you already broke that stuff several times.

Ok, I haven't really been following this terribly closely before now,
so I'm still getting a picture of how stable it all has been.  From
looking at the diff between 1.1.12 and 1.2beta2 there didn't seem to
be all that much that was incompatible.  I see that wasn't quite a
complete picture of the history before then.

> But now that I've split the libraries, at least the problem won't be
> subtle.

After the split we have no problem, the part that is changing is
cleanly separated from the part that is not, which is perfect.
It's how elegantly we get from the library that people are using
today to the new split form that is the immediate issue concerning
the debian folk.

> *Regardless* of what we do with the soname, the users of the dsp
> stuff as included from previous versions will get an error at start
> time.

No this is not correct.  The users of the dsp stuff from previous
versions will still be linked to the library with the old soname
which will still be on the system while they need it, and will
still work just as well for them as it will for people not using
the dsp code.

The only difference is that when applications not using the dsp
code try to compile with the new libspeex (with a new soname),
for them it will work perfectly and they need change nothing.
People trying to recompile code with dsp dependencies will find
things break that they need to fix, when they do that and upload,
the end user will go from using the old app linked with 'old'
libspeex, to using the new app linked with new libspeex, without
ever needing to be aware that some major transition just took place.

Nothing will ever 'break'.  Things only break how you describe
if we replace libspeex.so.1 without bumping the soname.  I'm not
sure why you think old apps will break with what we propose, but
I can understand why you would be concerned if you believe that.
I'm not sure how else I can explain that won't happen though...
Bumping the soname means we explicitly get to keep libspeex.so.1
for as long as we need it, it doesn't get purged the instant we
upload a libspeex.so.2 ...

> If we bump the soname, they'll get "can't find libspeex",

That won't happen because the lib was linked to libspeex.so.1,
which will still be on the system while some binary depends on it.
We don't remove libspeex.so.1 until the transition to libspeex.so.2
is completed for everyone.

> while if we don't bump the soname, we'll get "unresolved symbols".

You should get something like this at build time, but at runtime
for apps previously built with 1.2beta2 or earlier, you'll need
to set LD_BIND_NOW to find out about the missing symbols before
something tries to actually use it.

> The first is
> slightly better, but not worth annoying all the *other* users, who are
> just using libspeex and who would see things breaking for no reason.

I don't understand what you think they will have to be annoyed at,
nothing will break for those people, not their existing binaries,
nor when they try to recompile with a newer libspeex.  In both cases
everything will just keep working for those people.

Only the people who are expecting the code they have used will break
will actually experience a breakage, and even then only when they
try to recompile with the new library.  Their existing binaries will
continue to just work as well.

In the new soname scenario, the only people inconvenienced are the
people who used the unstable API, no one else is.

> > What will happen when we split speexdsp out though is a bit different.
> > All of those applications are now guaranteed to break.  Worst of all,
> > with lazy linking, they might not break until some point well into the
> > running when the missing feature is actually used -- at which point
> > the whole application will ungracefully die.
> 
> Most will have non-lazy linking as my experience goes.

the ld.so documentation for linux suggests symbols are resolved when
first referenced by default, and I've certainly seen things blow up
'mid-stream' in this way before.  I think Mac and some others might
be a bit more aggressive about binding everything early.

> Plus it should be fairly easy to see if something uses the dsp
> stuff. Not that many do anyway (any even less actually know how to use
> it properly!).

heh.  I can thoroughly sympathise with the latter problem.
I didn't mind reading your code for detailed answers, but I don't know
how to solve that one in the general sense yet, sorry ;{

The current list of packages directly depending on libspeex.so.1 are:

  libxine1
  asterisk
  iaxcomm
  yate
  xmms2-plugin-ices
  xmms-speex
  wengophone
  vorbis-tools
  vlc-nox
  twinkle
  sweep
  simpleopal
  python-renpy
  mplayer
  mpd
  moc
  liquidsoap
  linphone
  libxine1
  libshout3
  libsdl-sound1.2
  libopal-2.2-ptrace
  libopal-2.2-develop
  libopal-2.2
  libmediastreamer0
  libccaudio2-0.9-0
  libakode2
  kiax
  ihu
  idjc
  ices2
  icecast2
  iaxcomm
  gstreamer0.10-plugins-good
  glob2
  easytag
  aqualung

That's a fair bit of code to scan if you don't already know most of the
answers (which I currently don't).

> > The downside of that means that from the time we upload the new
> > libspeex to the time that all the affected packages are fixed,
> > they are all immediately broken for all users.
> 
> I don't see why you can't fix everything in one go.

For pretty much the same reason we can't demand you release a new
snapshot immediately -- coordinating a Good Time for 20 or 30 very
loosely connected people to do something all together isn't a game
with very good odds ;)  We have Sid (unstable) as a buffer for that,
but just because we do reserve the right to break anything and
everything in there, for no better reason than pure stupidity, that
doesn't make it a good or popularity gathering right to exercise very
often.

Yes the pain won't kill us, even at its absolute worst.  But for the
people that things do break for, The Speex Transition will become a
household name among unfortunate transitions before that...

I'd prefer to avoid that, and will do what I can either way, but I'll
have to be far more ninja to pull it off well if we do it the hard way.

> > I think using the technical solution is superior in this case,
> > because we can effect the same transition without any interruption
> > to the existing users at all.
> 
> I think you're assuming that the "new stuff" was ever stable before. It
> was not.

Yes I do understand that.  If it really has been breaking as much as
you say for the people using it, and there really are as few people
using it as you suggest, then maybe this won't be a big deal ...

The 'mistake' I see in the handling of the dsp code was that it was
provided in libspeex for so long.  You've clearly done exactly the
right thing to correct that.  I see the soname as the blunt instrument
of choice for giving end users a smooth upgrade path in this situation.

It is pretty much precisely what we are proposing for libspeexdsp,
when the api changes incompatibly we just bump the soname, nothing
breaks for existing users of speexdsp, only when they try to recompile
with the new speexdsp will any problems start to be evident.  Which
seems like exactly the right place to put the Solution People who need
to actually do the work to fix it.

You get to let the api be as stable or unstable as you please through
the development cycle, and people who need new features but aren't
right on the bleeding edge get to keep the old api versions around
for as long as they need them.

It's a win/win that seems appropriate to use here, even if people
have been accustomed to doing it the 'hard way' in the past ...

> At least now that we switch to two different libs, and break won't
> be subtle as it would have been for the previous changes.

Yes, however big the bang ends up being, it should burn out loud
and fast ;)

> > libspeex2 will become the default, so as people upload new versions
> > of their apps, they will have been fixed however they need to be.
> > All the end user sees is one day their app gets updated, at no point
> > it is ever broken because "nobody has updated it yet for the speex
> > transition" ...
> 
> Whatever you do, do *NOT* call this libspeex2. I'll start getting lots
> of emails asking what the hell libspeex2 is, why they only see version
> 1.2, and whether version 2 is compatible, ...

That was just me using the same N in the package name as for the
soname in the package in the example, at this stage it will be
libspeex1 with libspeex.so.1 in it until I hear otherwise about
your plans for any soname bump.

> > Do you have a scenario where things do break unnecessarily if we
> > bump the soname?  The only real downside I see is that apps which
> > could automatically get the new lib won't get it until they are
> > next rebuilt? 
> 
> Well, it would definitely make dependencies easier.

Most of the apps in the list above are all going to have to be rebuilt
once or more for a change in some other dependency they have over the
course of a release cycle.  So even if someone doesn't feel the speex
update is urgent enough to flag a rebuild, something else will likely
do that before too long anyhow.

> > Obviously we don't want to force that on people
> > any more than ever necessary, but compared to the 'big bang' type
> > transition, the cost does not seem high.
> 
> Note that the 'big bang' has happened (in a worse form than this)
> before. Nobody died and you don't even seem to remember people complaining.

Oh it happens all the time with lots of the code that gets packaged
for the distro.  We're no strangers to it.  But the people complaining
are burn'd into mah brains -- I won't ever forget some of them, no matter
how hard I try ;)

Maybe the speex users are a bit more civil...  I will hope so :)

> At least it's in stereo, which very few people use with Speex
> (for good reason -- it sucks).

I have support for it in our glue layer (mostly because it was trivial
to add), but don't really have an immediate need that will exercise it
much yet.

> Few libraries link with Speex *and* use the DSP stuff. The only one I'm
> aware of is OPAL (and it doesn't use the DSP functions properly anyway
> -- though that's besides the point).

I don't think I'm supposed to say that some apps deserve every crash
that brings them down while I've got my debian hat on, but that won't
make it less true ...

I do try to take the bit about making even the stupid people look good
pretty seriously though, so I like to err on the side that makes it
harder for people to screw up in ways that burn other people whenever
that is practical.  It's not always perfectly right, but it certainly
generates the least hate mail ;-)

> > I think what is different is that the earlier changes rolled the dice
> > and won, either nobody else noticed them at all, or they noticed them,
> > remembered what you'd told them, fixed whatever broke and moved on.
> > 
> > This time, everyone is sure to notice.  They still may not grumble,
> > but some otherwise innocent users are almost surely going to get
> > caught up in the flak.  We've changed the equation from slim chance
> > it will break something, to certainty it will break everything that
> > currently touches speexdsp.
> 
> Why are people more likely to notice now. In the previous cases, it was
> even worse because I might have added a single parameter and the app
> would do all kinds of silly things before crashing and the user would
> have no idea what the hell's going on (yes, Ekiga ships with the DSP
> stuff enabled by default).

Yeah, I could be wrong about that, maybe it will just be business as
usual for the people on the pointy end of this, and that will be ok
for them.

I just see a tool that can ensure this is painless for everyone, and
I'm curious why you are hesitant to put it to use when this clearly
is a time when it could end a history of painful transitions for
some, and make them smooth for everyone.

I still don't understand what you think will make "everything break",
but that might be a problem we need to solve over beer sometime.
We don't have to do it now if we each can't see what the other is
missing yet.


> > If you still think that with all the above taken into account,
> > then we'll call that final.  Whichever way it goes, we'll all
> > learn something from how it unfolds  ;)
> 
> Yes, I still think that.

I'll happily answer any questions you might be left hanging with,
but otherwise ok, I won't harp on, we'll run with what you are doing.

> >> The resampler in beta2 was definitely broken, badly. It would produce
> >> bad quality output in many cases and would crash in some corner cases.
> > 
> > Ahh, bad output I could have missed, up to this point I've largely been
> > feeding pure tones through it and I don't expect them to perform well,
> > it's not really what you're optimising for.  They were just good for
> > spotting the sort of things I was looking for at the time.
> > 
> > The fidelity degraded heavily on some of those in 1.2beta2 relative
> > to whatever I was using prior to that (probably 1.1.12?) -- if that
> > shouldn't be, let me know and I'll dig up a test case.
> 
> The resampler's first release was in 1.2beta2. I hadn't even started it
> when I released beta1. The problem is that I broke it just before
> releasing beta2. The problem was quality degradation, but it only
> happened for "simple" conversion ratios (e.g. 16kHz to 48kHz), but not
> for complicated ones (e.g. 44.1 -> 48) that were using a different path.

Ok.  Sounds like what I was seeing was in the codec then, which was
my original guess on that.  I only had a few tests running through
the resampler, and any extra glitch there I'd have probably dismissed
as from the same cause in the codec.  I'm pretty sure I ran a few
8/16/32 conversions through it, but looking at the tests that stayed,
its only doing 44 -> 8 now, which should be in the safe path.

Does that sound like something you'd expect from the codec changes,
or something I should get you a better report about?

> The plan so far is to have one last change. It might even be
> backward-compatible, but I can't promise that (unlikely, but possible).

I'm just trying to figure out what the odds on our libspeex1 libspeexdsp1
at release time bet might be.  We could lose it if you do Too Well ;-)

> If you want mumble to work, you'll need the current svn, which is pretty
> much like beta3 except for the stuff that makes Mumble work.

I'm about to run the first builds of beta3 with the extra libspeexdsp
packages, sorting out what breaks and what doesn't will probably keep
us amused for a little while, and unless I'm mistaken mumble still has
a few things they need to do too ...

We'll see if they start making louder noises than everyone else before
you are ready for a beta4 or similar.

> >> 4) Need to put back a decent VAD.
> > 
> > We might have to define 'decent' before I can decide if I'll
> > be of any help there ;-)
> 
> Well, I had one that sort of worked and that I had to remove. The
> solutions are to either:
> 1) Being back the old one and convert it to fixed-point
> 2) Write one based on the same principles, but less messy

I might have to brush up on what you've been using, I fear what
we have been using for this would seem shockingly crude to you.
But it hasn't had very demanding users in the past, so I might
have a reason to look into this more deeply at some later point.

  Ron