[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#682010: [mumble] Communication failures due to CELT codec library removal



On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> > That point is currently still true.  Every existing client has the ability
> > to *decode* speex if speex packets arrive.
> > 
> > The only thing removed from recent clients was the ability to encode them.
> > This is what we need to restore.
> 
> I'm afraid I don't recall, and I don't seem to be able to find in the
> email thread, the answers to two questions related to this:

I don't think we got to these specific points, so I don't think you missed
previous discussion on them (or if you did, then I did too ;)

> These `recent' clients which can't encode speex are where ?  Have they
> been released by upstream ?  Are they in Debian ?

The last formal release of mumble was 1.2.3 in Feb 2011.

The commit to "Remove Speex encoding code" was done in mid May 2012.
I had thought the -349 snapshot from git uploaded to debian was the only
one that contained this change (that's the one still blocked in unstable),
but from the git history, the -348 release in testing may have this change
too.  348 was uploaded to debian on the 24th May 2012, a couple of days
after the changes which added Opus support and removed speex support
happened upstream.

The 1.2.3-2 that Ubuntu has been shipping definitely doesn't have this
change, so it should only be anything pulled from Debian in the last
month or two that might be affected here.


> And presumably there is some reason why upstream don't like speex.
> What is that reason ?

The reason the upstream people who've been pushing back at this have
been giving me is that they think "it sucks" for audio quality.

Which to be honest I don't really understand, and I haven't yet been
able to elicit a clear explanation of what they think qualitatively
falls down about it for this particular use.

>From the purely technical side of things:

Speex is a speech coder, which means it's very efficient at coding
speech signals, it requires very little bandwidth to transmit them
with much better than toll quality telephone fidelity (I'm talking
good land-lines here, not mobile phone quality) - but it's not so
hot at things like full-band complex music.

Celt on the other hand, was designed for low-latency interactive
music.  So it requires much more bandwidth, but you could wire a
remote orchestra together with a good conductor, and have them all
play together.  [1]


So for simple conversational speech, speex should be more or less
indistinguishable from raw PCM audio for many people.  You can try
this yourself with speexenc/speexdec from the speex package on some
recorded speech to hear what I mean.  The only situation I imagine
where that would degrade notably would be if you have lots of loud
and complex background noise, to the degree where conversational
speech would be challenging in its own right.

Maybe that is true for the gamers, but when I asked I didn't get
any confirmation that this was what the problem they saw was - so
I'm guessing a bit here, based mostly on the knowledge of what the
codecs themselves are capable of.

I am actually likewise curious to understand this better if that's
not the reason.  It's not surprising celt can sound better, but it
is quite surprising if speex actually sounds Bad.  And for people
just talking, and who pay for their traffic by the MB, or who only
have a low bandwidth pipe, celt may not be the best choice for them
at all anyway.


In the discussion I had with Thorvald, he noted that when they first
switched to celt, they'd assumed that nobody using this would mind
spending more than 40kbs to send audio (since most of them were
playing online games using much more bandwidth than that) - but that
apparently wasn't completely true, and many people did still want the
lower bandwidth option of speex.  So I'm not quite sure what triggered
the recent motivation to remove encoding it completely either.


 Ron

[1] - and just to complete the spectrum here, Opus is a hybrid codec
      which implements a speech coder that is more efficient and better
      quality than speex, along with the later evolution of celt for
      full band music, so you'll get both better quality and lower
      bandwidth than either of the other options provide.


Reply to: