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

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

On Wednesday, July 25, 2012 03:40:52, Nicos Gollan wrote:
> Hi,
> On Wednesday 25 July 2012 03:50:23 Chris Knadle wrote:
> > The way you've described this, /if/ the trick with Speex does work, and
> > the Debian version of Mumble ships without CELT, it would mean that if
> > any Debian user shows up on a public server then all users would switch
> > to using Speex. If that's the case, then the audio quality of Speex vs
> > Celt and the latency each has matters to an extent.
> If "the trick with speex" works and is actually deemed necessary, then
> we're talking about a package providing the absolute minimum of
> interoperability without any ambition to providing quality. And yes, for
> it to work, it would need to switch all clients within hearing range to
> using speex with all the penalties in quality and latency that brings.

Yeah... I'm not liking the sound of that.  For instance one of the things that 
are common on public Mumble/Murmur servers are one or more "music channels" 
among the many other channels for teams of gamers.  Forcing all of that 
through a low-quality codec meant only for voice communication sounds very 
undesirable from the user perspective.

> However, as suggested earlier, statistics also show that users on Linux
> platforms make up not quite 2% of the overall userbase, and users affected
> by the hack would be well below that (my guess would put them under one
> per mil). With that in mind, it would be easy for users to just kick the
> offending handful of clients worldwide off their servers if the need
> arises, since it would be a very rare occurrence. That makes the impact on
> the overall userbase absolutely negligible.

[I'm sure you know the following, but I'm explaining this in more detail for 
those that may not be familiar with it.]

Normally users cannot kick nor ban another user off the server.  To kick an 
offending client off the server would require SuperUser priviliges in the 
Mumble/Murmur server, or for kick/ban priviliges to be delegated to specific 
users via Groups or ACL rules in the server.  After that, this would involve 
right-clicking on the suspected offending client and getting Information on 
the client version, *somehow* figuring out that that version of Mumble was 
causing the problem (i.e. "the Debian version of Mumble is a problem" from a 
web search), and then finding someone with kick/ban priviliges to get the 
offending client off.  Then presumably someone has to leave the server and 
return in order to get the server to renegotiate the codec used.

I wouldn't characterize the above as "easy" -- although it is easy in the 
sense that it doesn't require reconfiguring the host machine to do it.  It 
would be easier for users to text the offending client and ask that the user 
leave, but this would also involve understanding and explaining the situation.

  -- Chris

Chris Knadle

Reply to: