Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
This is a bit of a dead issue now, but I wanted to come back to it: Steve Langasek writes (Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote: The objection is that the issue has been raised before the CTTE, so it needs to be resolved first before action is taken. If the original petitioner is satisfied with the solution and no longer feels the need to involve the TC, I don't see any reason for the TC to remain involved. Certainly historically, we have considered our job done once there's no longer a dispute that someone wants escalated to the committee. It's not at all our charter to fix all the bad bugs, only to adjudicate when consensus can't be reached on its own. If Chris and Ron *are* working together now towards an agreed solution, I'd much prefer that we let them get on with it. I think this is the right approach when it seems that all the important aspects of the problem have been considered by everyone. I don't think, though, that we should have a hard and fast rule that we should drop a case immediately as soon as the referrer (the person who brought the matter to the TC) says once that they are satisfied. In particular if it appears that the referrer may be acting in haste or out of only a partial understanding, it is part of our job to ask questions and double check. It seemed to me at the time that Chris's understanding might not have been complete. Ron was very keen to get his particular understanding implemented ASAP, but I thought a more reflective approach was warranted. And indeed after Chris had a bit more time to think about it and do some more checks it turned out that things were more complicated than they seemed. It may be that it's Ian's intention to take up this issue in Chris's stead because he himself thinks there's a problem that he wants to put before the TC. That's fine too, but I think in that case, Ian, you should state this explicitly I didn't intend to take this up in Chris's stead. And indeed if the parties come up with a solution which Chris and other parties are happy with after appropriate reflection and consideration, and which meets our goals in this context for wheezy, then it seems unlikely to me that the TC would need to do anything. However having said that as a matter of procedure I think that once a dispute has been brought to the TC, the TC is /entitled/ to make a decision even if the original referrer has changed their mind. Usually it wouldn't be appropriate or necessary for us to do so, but I think the power is there. As an example of a hypothetical situation in which we would exercise this power: suppose the maintainer whose decision is being referred abuses social pressure of some kind to persuade the referrer to withdraw the referral (perhaps just by being rude or by threatening some kind of retaliation). Just to be clear, I'm not accusing anyone in this dispute of having done any such thing to Chris. If such a situation arose I'm sure the TC should make a ruling regardless; and if the TC has the power to rule in such an unpleasant hypothetical situation, it seems to me it also has the power to (for example) delay disposing of a work item while the TC's members make sure the referrer and others have properly considered all of the implications. (and, logically, recuse yourself from voting on it under 6.1.2, 6.1.3, or 6.1.4 since you're then a party to the disagreement). Of course there is no requirement for TC members to recuse themselves from voting on issues for which they are one of the referrers. The only exception is clearly stated in 6.3(2) and applies when the TC is voting whether to overrule one of its own members. This seems to me to be related to the issue of whether TC members should recuse themselves from voting on matters where they've already previously expressed an opinion. We have consistently rejected such a rule. Ian. -- 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/20493.20833.120226.584...@chiark.greenend.org.uk
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote: 1) Fix up 348 from Wheezy so it compiles and uses the CELT codec library [very undesirable] 2) Same as 1) but with embedded CELT (would need testing) 3) drop mumble from Wheezy If we go with 3), would the server depend on having the embedded CELT library available too or could we somehow ship a security-supported murmur? (I.e. if the potential crashes we're talking about are on the client side.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#682010: [mumble] Communication failures due to CELT codec library removal
Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote: 1) Fix up 348 from Wheezy so it compiles and uses the CELT codec library [very undesirable] 2) Same as 1) but with embedded CELT (would need testing) 3) drop mumble from Wheezy Of these 2. would seem to be the best option. Mumble is pretty widely used in some communities and I certainly think we should try to have software in wheezy which can (i) provide a server for mumble clients (ii) talk to mumble servers (iii) is generally compatible with the existing deployed base (both inside and outside Debian). Personally I don't think there is much to prefer between 1 and 2. Is all that's stopping us from fixing this is overcoming our resistance to an embedded library copy ? If so I think we should just go ahead. The difference in security supportability of a single embedded library copy versus a separately library package with a rdep isn't very great. The difference mostly consists of the discoverability of the embedded copy - and after this conversation I think we can reasonably hope that everyone will know that mumble needs attention for security bugs in celt 0.7.1. We should confirm this with the security team but I don't imagine they'll have an objection. Ian. -- 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/20493.24820.868658.530...@chiark.greenend.org.uk
Bug#682010: [mumble] Communication failures due to CELT codec library removal
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: These `recent' clients which can't encode speex are where ? Have they been released by upstream ? Are they in Debian ? And presumably there is some reason why upstream don't like speex. What is that reason ? Ian. -- 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/20493.25076.808386.747...@chiark.greenend.org.uk
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 10:34:28, Ian Jackson wrote: Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote: 1) Fix up 348 from Wheezy so it compiles and uses the CELT codec library [very undesirable] 2) Same as 1) but with embedded CELT (would need testing) 3) drop mumble from Wheezy Of these 2. would seem to be the best option. I agree. Pros: - Solution should work for both Wheezy and Sid (-2 in Sid currently has no celt support, and celt is the most widely used codec in mumble on the 'net) - Would use celt 0.7 as well as 0.11 - Celt library can be removed, which a lot of effort has gone into Cons: - Larger diff in mumble - Would greatly irritate mumble maintainer Mumble is pretty widely used in some communities and I certainly think we should try to have software in wheezy which can (i) provide a server for mumble clients (ii) talk to mumble servers (iii) is generally compatible with the existing deployed base (both inside and outside Debian). Personally I don't think there is much to prefer between 1 and 2. Is all that's stopping us from fixing this is overcoming our resistance to an embedded library copy ? If so I think we should just go ahead. Pros: - Smaller diff in mumble Cons: - Only uses celt 0.7 - Proliferates library that upstream requested removal of - No DD found to maintain celt 0.7 library (yet) - Would somewhat irritate mumble maintainer The difference in security supportability of a single embedded library copy versus a separately library package with a rdep isn't very great. The difference mostly consists of the discoverability of the embedded copy - and after this conversation I think we can reasonably hope that everyone will know that mumble needs attention for security bugs in celt 0.7.1. Right. We should confirm this with the security team but I don't imagine they'll have an objection. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
Chris Knadle writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Monday, July 23, 2012 10:34:28, Ian Jackson wrote: Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote: 1) Fix up 348 from Wheezy so it compiles and uses the CELT codec library [very undesirable] 2) Same as 1) but with embedded CELT (would need testing) 3) drop mumble from Wheezy Of these 2. would seem to be the best option. I agree. Pros: - Solution should work for both Wheezy and Sid (-2 in Sid currently has no celt support, and celt is the most widely used codec in mumble on the 'net) - Would use celt 0.7 as well as 0.11 I'm not sure I follow this. Are you saying that enabling the embedded celt would necessarily involve enabling /two/ versions of celt ? (And you mention `0.7' and `0.11' neither of which are the same as `0.7.1' so I'm confused about that too.) Surely we want to avoid having multiple different versions if at all possible. Is it essential to support anything other than 0.7.1 ? I thought upstream had declared 0.7.1 to be a baseline so that would be sufficient. And if 0.7.1 is sufficient, can it be done using an embedded copy right now with a build system change, or would we have to dump a special copy of celt 0.7.1 into the mumble source package ? Cons: - Larger diff in mumble Is it in fact a substantial diff ? I thought it was essentially a configure option. - Would greatly irritate mumble maintainer Rather than consider someone's emotional state, I'd rather focus on their views. That is, if this is a bad idea according to the mumble maintainers then I'd like to hear why they think so. Personally I don't think there is much to prefer between 1 and 2. Is all that's stopping us from fixing this is overcoming our resistance to an embedded library copy ? If so I think we should just go ahead. Pros: - Smaller diff in mumble Cons: - Only uses celt 0.7 See above. Thanks, Ian. -- 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/20493.34097.812398.516...@chiark.greenend.org.uk
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. -- 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
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 13:09:05, Ian Jackson wrote: Chris Knadle writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Monday, July 23, 2012 10:34:28, Ian Jackson wrote: Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote: 1) Fix up 348 from Wheezy so it compiles and uses the CELT codec library [very undesirable] 2) Same as 1) but with embedded CELT (would need testing) 3) drop mumble from Wheezy Of these 2. would seem to be the best option. I agree. Pros: - Solution should work for both Wheezy and Sid (-2 in Sid currently has no celt support, and celt is the most widely used codec in mumble on the 'net) - Would use celt 0.7 as well as 0.11 I'm not sure I follow this. Are you saying that enabling the embedded celt would necessarily involve enabling /two/ versions of celt ? Yes AFAIK. (And you mention `0.7' and `0.11' neither of which are the same as `0.7.1' so I'm confused about that too.) The mumble source package seems to contain celt 0.11.0 and 0.7.0. The celt library contains celt 0.7.1. Surely we want to avoid having multiple different versions if at all possible. Is it essential to support anything other than 0.7.1 ? AFAIK, no. I thought upstream had declared 0.7.1 to be a baseline so that would be sufficient. That was my understanding too, but upstream seem to be using 0.7.0 from what I can tell. [As such I'm likewise asking the same questions you are.] And if 0.7.1 is sufficient, can it be done using an embedded copy right now with a build system change, or would we have to dump a special copy of celt 0.7.1 into the mumble source package ? I'm working on the assumption that celt 0.7.0 in the source package can be embedded using a build system change. Cons: - Larger diff in mumble Is it in fact a substantial diff ? I thought it was essentially a configure option. Source-wise it's likewise my assumption also, but I was also considering the binary diff, if you will. - Would greatly irritate mumble maintainer Rather than consider someone's emotional state, I'd rather focus on their views. That is, if this is a bad idea according to the mumble maintainers then I'd like to hear why they think so. Likewise -- I'm just trying to take the maintainer's wishes into account. Personally I don't think there is much to prefer between 1 and 2. Is all that's stopping us from fixing this is overcoming our resistance to an embedded library copy ? If so I think we should just go ahead. Pros: - Smaller diff in mumble Cons: - Only uses celt 0.7 See above. Celt 0.7.1 in the celt library. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 04:52:29, Nicos Gollan wrote: Hi, On Monday 23 July 2012 00:31:27 Chris Knadle wrote: This means that the Opus-only client ruins the audio connection for everybody else that's connected, at least in this case. That happens because the maintainer patch 20-add-opus-threshold-option sets the threshold variable default to 1, which is a pretty nonsensical value in most situations. It only really makes sense to set it to 0 or 100, unless you want to fabricate some really weird behaviour in codec negotiation… Yes I see that opusthreshold is commented out, and iOpusThreshold = 1. I've verified that this patch doesn't exist in the 348 version in Wheezy -- nor does it contain patches in relation to Opus. In that case, any client with Opus support should trigger the issue, no matter if it supports CELT. Just for completeness' sake, this is _not_ an upstream issue, the value is initialised to 100 there. I guess manually setting opusthreshold=100 in your murmur.ini would restore sane behaviour on the server side, but I'm not inclined to dig through the other maintainer patches to see what else is interfering at this point. When it comes to the -2 version in Sid I hope it will only be necessary to get the build fixes required to build 348 -1 in Wheezy. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201207231430.48300.chris.kna...@coredump.us
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 13:26:57, Don Armstrong wrote: On Mon, 23 Jul 2012, Chris Knadle wrote: On Monday, July 23, 2012 10:34:28, Ian Jackson wrote: Of these 2. would seem to be the best option. I agree. [...] I believe in order to actually evaluate any of these solutions, someone is going to have to prepare binaries, and do an table showing the tested (not theoretical) compatibility of with multiple different clients (and servers?) to their solution's server and client. I propose that whoever wants to see a particular solution actually sit down and do the work for their particular solution, with sources, binaries, interdiffs, and compatibility table conveniently available in some public location. That sounds reasonable. I might need occasional advice but otherwise I think I can handle this. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201207231443.55522.chris.kna...@coredump.us
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Mon, Jul 23, 2012 at 06:09:05PM +0100, Ian Jackson wrote: Chris Knadle writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Monday, July 23, 2012 10:34:28, Ian Jackson wrote: Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote: 1) Fix up 348 from Wheezy so it compiles and uses the CELT codec library [very undesirable] 2) Same as 1) but with embedded CELT (would need testing) 3) drop mumble from Wheezy Of these 2. would seem to be the best option. I agree. Pros: - Solution should work for both Wheezy and Sid (-2 in Sid currently has no celt support, and celt is the most widely used codec in mumble on the 'net) - Would use celt 0.7 as well as 0.11 I'm not sure I follow this. Are you saying that enabling the embedded celt would necessarily involve enabling /two/ versions of celt ? (And you mention `0.7' and `0.11' neither of which are the same as `0.7.1' so I'm confused about that too.) This is absolutely not _necessary_, and not at all what I had in mind in the previous discussions of this option. It is _possible_ for mumble to embed many versions of celt simultaneously, and perhaps Nicos and Chris had discussed this privately, but this is not what we should be doing here. If we take this option at all, then we should use precisely the same celt code we have been using before now, the 0.7.1 release. Surely we want to avoid having multiple different versions if at all possible. Absolutely. Anything else only increases our exposure surface to unmaintained code. Is it essential to support anything other than 0.7.1 ? No. We have never shipped a version that supported anything else. I thought upstream had declared 0.7.1 to be a baseline so that would be sufficient. Correct. (well, ostensibly correct, that's what upstream declared, but apparently there are live servers in existence which don't respect this and want to force other arbitrary versions of celt too). For decoding speex actually appears to be the only baseline that we really can trust all clients will have and all servers will support. And if 0.7.1 is sufficient, can it be done using an embedded copy right now with a build system change, or would we have to dump a special copy of celt 0.7.1 into the mumble source package ? I'll have to look at exactly what has been included in the recent tarballs, the upstream git repo is a bit of a hodge-podge of git sub-modules, embedding various versions of various external libs, all of which we currently do not use at all. There will be some diff, but I haven't looked at how big in detail yet. Cons: - Larger diff in mumble Is it in fact a substantial diff ? I thought it was essentially a configure option. That will depend on the above, but if it's substantial it should be fairly much limited to a single subdirectory adding the celt code. I'm not concerned about our ability to do this correctly should we choose to, only about the advisability of continuing to use celt at all. - Would greatly irritate mumble maintainer Rather than consider someone's emotional state, I'd rather focus on their views. Amen. That is, if this is a bad idea according to the mumble maintainers then I'd like to hear why they think so. My primary concern is with the fact we would be shipping very complicated code, that only about 3 people in the world really understand, and which has no committed ongoing maintainer from among them or anyone else. If there is a consensus among the members of the TC and the security team that the risk of doing that is justified by other factors, then I'll consider the peer decision making process to have worked as it should, and quite the opposite of being 'irritated', I'll be quite relieved that this decision and its possible consequences do not fall on my head alone. I was not comfortable unilaterally making the decision to continue shipping celt with the knowledge I have of its situation, and I wasn't going to be browbeaten by users who shared no part in the risk they wanted to expose others to. That's very different to the TC putting its judgement on the line, and the security team committing to do the work should it come to that. If they all agree this is our best option, then I have no problem with deferring to that opinion. As I said previously, it won't take a formal vote to convince me if consensus is that this is the best thing to do. I think I'd still like to see us explore the speex option. But the release clock is ticking, and I'd be lying if I said I wasn't anxious about squandering what time we have left by not having real users really out testing all this and reporting the bugs they find. The bottom line on the compatibility matrix is that the *only* way to ensure
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Mon, Jul 23, 2012 at 02:38:19PM -0400, Chris Knadle wrote: On Monday, July 23, 2012 13:16:55, Ron wrote: On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote: […] 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. I seem to recall that the early versions of Mumble that I used defaulted to using Speex. I seem to remember it sounding sort of like a so-so cellphone connection, sort of like the person(s) on the other side sounded like they might be slightly underwater. i.e. works but not great, whereas CELT sounds very clear [as does Opus]. I can't be positive about this though because I might be mixing this memory up with my memories of other VoIP packages I've used over the years, so I'm likewise curious to hear what Speex sounds like again. That's the classic artifact introduced by an echo canceller hunting for phase lock, which is exactly what causes it in cell phone connections too. It's not an artifact of the codec itself. And unless you really are completely misremembering, really early versions of mumble used speex 1.1, which is an inferior codec to what we have today, but is still not responsible for introducing that effect. Ron -- 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/20120723194311.ga18...@audi.shelbyville.oz
Bug#682010: [mumble] Communication failures due to CELT codec library removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.07.2012 19:16, Ron wrote: Celt on the other hand, was designed for low-latency interactive music. Fwiw, I've seen numerous people asking in #mumble how to stream music over Mumble in a way that it sounds reasonable, so it might not be *just* about speech here. As you noted earlier, gamers are somewhat special when it comes to what they do with stuff. :) Cheers, Michael - -- Öffentlicher Schlüssel: 48F81543 - Michael Ziegler (Svedrin) Wo kämen wir denn da hin, wenn jeder nur fragte Wo kämen wir denn da hin?, aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir gingen?(Autor unbekannt) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQDaw5AAoJEEn0ejpI+BVDumEH/jnHQES0mlhl6xYWCuvUrWVL qGaqXkE6Ifa08XFornBaPjaw6ny6eT0/ZvRP0jtjOf0kIbCr+sQLhmiTJGj0WwHa WOGmkvoHhs3zF90Cio+50hEujcH+pMU9dYVkGA+bZEwIbJ8t8uMtpgz9Yd275mk1 6wt84lGhgb3tiG8Fly8N+Q5QmAUoijuQ0LyXqp50+keGN+x6hqh45cluuydI+ryG gWaixIzm7Hi7DFBEdlD1BZDY9N4fWmgOJpQ7oOxbqGsif+A8CsCwj0zKA81IEXPS v3jTXQEALKqoeAxc3fAvO86AzfA3s+dIeOg8HKIsuTeCFwxHenYCpX46oTvDJ70= =LYkU -END PGP SIGNATURE- -- 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/500dac39.6030...@funzt-halt.net
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 15:25:17, Ron wrote: On Mon, Jul 23, 2012 at 06:09:05PM +0100, Ian Jackson wrote: Chris Knadle writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal): On Monday, July 23, 2012 10:34:28, Ian Jackson wrote: Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due to […] - Would use celt 0.7 as well as 0.11 I'm not sure I follow this. Are you saying that enabling the embedded celt would necessarily involve enabling /two/ versions of celt ? (And you mention `0.7' and `0.11' neither of which are the same as `0.7.1' so I'm confused about that too.) This is absolutely not _necessary_, and not at all what I had in mind in the previous discussions of this option. It is _possible_ for mumble to embed many versions of celt simultaneously, and perhaps Nicos and Chris had discussed this privately, but this is not what we should be doing here. If we take this option at all, then we should use precisely the same celt code we have been using before now, the 0.7.1 release. I have no objection. There has been no private discussion with any of the parties in the bug AFAIK. The main reason I was considering the embedded version was because the celt library is removed in Sid. The only possible benefit of using celt 0.11.0 is only if it somehow improves interoperability with other distros, that from what you mentioned used embedded celt -- but this is certainly /not/ a requirement. Surely we want to avoid having multiple different versions if at all possible. Absolutely. Anything else only increases our exposure surface to unmaintained code. I think I agree with that. […] I thought upstream had declared 0.7.1 to be a baseline so that would be sufficient. Correct. (well, ostensibly correct, that's what upstream declared, but apparently there are live servers in existence which don't respect this and want to force other arbitrary versions of celt too). For decoding speex actually appears to be the only baseline that we really can trust all clients will have and all servers will support. It will be good if a solution with Speex will work out such that celt can go away. On that I think we're all on the same page, but I have my doubts if it will work with existing servers. Hopefully it does. […] That is, if this is a bad idea according to the mumble maintainers then I'd like to hear why they think so. My primary concern is with the fact we would be shipping very complicated code, that only about 3 people in the world really understand, and which has no committed ongoing maintainer from among them or anyone else. If there is a consensus among the members of the TC and the security team that the risk of doing that is justified by other factors, then I'll consider the peer decision making process to have worked as it should, and quite the opposite of being 'irritated', I'll be quite relieved that this decision and its possible consequences do not fall on my head alone. I was not comfortable unilaterally making the decision to continue shipping celt with the knowledge I have of its situation, and I wasn't going to be browbeaten by users who shared no part in the risk they wanted to expose others to. The term browbeaten is objectionable, as from our point of view mumble became completely unusable to talk to the rest of the world, there wasn't sufficient information available to understand the issue, and ... so on. Please just try to stick to the technical issues so I may do the same, because those are things we're much more likely to agree on. That's very different to the TC putting its judgement on the line, and the security team committing to do the work should it come to that. If they all agree this is our best option, then I have no problem with deferring to that opinion. As I said previously, it won't take a formal vote to convince me if consensus is that this is the best thing to do. Cool. I think I'd still like to see us explore the speex option. But the release clock is ticking, and I'd be lying if I said I wasn't anxious about squandering what time we have left by not having real users really out testing all this and reporting the bugs they find. The bottom line on the compatibility matrix is that the *only* way to ensure we really are compatible with all extant systems is to: - Ship with speex reenabled. - Ship with all seven or so versions of celt enabled. - Ship with opus enabled. Seven versions of celt? No, I'm not looking to enable THAT. I think we can all quickly agree that shipping with more than one version of celt is crazy-talk, and the only option we need to consider there is 0.7.1. No objection. Speex is our most certain baseline, because all clients support it, and no server support is required. Opus support we need, because we likewise have no guarantee that Fedora or other
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 15:43:11, Ron wrote: On Mon, Jul 23, 2012 at 02:38:19PM -0400, Chris Knadle wrote: On Monday, July 23, 2012 13:16:55, Ron wrote: On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote: […] 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. I seem to recall that the early versions of Mumble that I used defaulted to using Speex. I seem to remember it sounding sort of like a so-so cellphone connection, sort of like the person(s) on the other side sounded like they might be slightly underwater. i.e. works but not great, whereas CELT sounds very clear [as does Opus]. I can't be positive about this though because I might be mixing this memory up with my memories of other VoIP packages I've used over the years, so I'm likewise curious to hear what Speex sounds like again. That's the classic artifact introduced by an echo canceller hunting for phase lock, which is exactly what causes it in cell phone connections too. It's not an artifact of the codec itself. And unless you really are completely misremembering, really early versions of mumble used speex 1.1, which is an inferior codec to what we have today, but is still not responsible for introducing that effect. That all sounds reasonable. Back then I think I was using many of the default settings and as such could have been using echo cancelation. These days I've turned that off because it can sometimes cause echo rather than canceling it. Speex 1.1 sounds familiar. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201207231618.35863.chris.kna...@coredump.us
