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. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120723171655.gy18...@audi.shelbyville.oz