[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 Sunday, July 22, 2012 04:35:00, Ron wrote:
> On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
...
> > [Special thanks goes to Nicos for watching our backs here.]
> 
> Just to be clear here, because at some point Ian described Nicos as being
> "a mumble developer", and you have now declared him a "sage" ...

You've misquoted me.  I said "he's consistently given us sage technical 
advice".

> $ git log master | wc -l
> 30363
> 
> $ git log master | grep Nicos | wc -l
> 12
> 
> And all of those commits afaics relate to GUI overlay stuff for games,
> nothing at all to do with the protocol negotiation we are talking about
> here ... 

Nicos is the only one that has hinted to how the protocol negotiation works; 
being judgmental about his commits isn't going to help.  If you know more 
about how the selection algorithm works, that would be good, but I haven't yet 
heard you discuss the subject when it has come up.

> So I think I'd still rather put my trust in the the opinion
> of Thorvald about what can be made to work, than in someone who has said
> repeatedly, "Debian should just remove this, nobody cares because nobody
> uses Debian anyhow".  Which is also clearly quite incorrect, or we wouldn't
> be having this discussion at all.

I'm quite willing to discuss Thorvald's plan when he comes back.

> The current facts are:
> 
>  - The server is currently 100% broken in testing, and will remain so
>    for our users for as long as this is blocked here.

The current -2 is also undistributable, so this doesn't really matter.  You'll 
see why.

I just found something out about the Opus-only client and the codec selection 
by the server.

This test involves four Mumble clients: 
  - "348" client from Wheezy (has Opus and CELT)
  - "1.2.2-6+squeeze1" client from Stable (lacks Opus)
  - "361" Windows developer snapshot (lacks Opus)
  - "349" client from Sid (has Opus only)

And the server version is again -2 from Sid.

Steps:
  1.  "361" Windows client connects (Codec CELT)
  2.  I connected the "1.2.2-6_squeeze1" client; doesn't show which
      codec is use, but it's CELT
  3.  I connect my "348" client, connection shows Codec CELT
  4.  Talk a while -- everything works
  5.  I connect the "349" client from Sid, shows Codec OPUS
  6.  All audio connections for everybody DO NOT WORK from here on.
      "348" client still shows Codec CELT.
      As long as the "349" client from Sid is connected, disconnecting
      and reconnecting any other client gets a message from the server
      "Warning: Your client doesn't support the Opus codec, you won't
       be able to talk or hear anyone.  Please upgrade to a client with
       Opus support."
  7.  Disconnect the "349" client
      Audio connections still do not work.
  8.  In order to get the audio connection to work again between the
      clients that have CELT, one of them must disconnect and then
      reconnect in order to get the server to renegotiate which codec
      is used.

This is 100% repeatable.

This means that the Opus-only client ruins the audio connection for everybody 
else that's connected, at least in this case.

From seeing this I really think releasing a client that only has the Opus 
codec available is a directly detrimental plan.

It also implies that the current version of the server seems to choose using 
Opus over everything else, regardless of whether the other clients have it.

[…]
>    Then provided we have a clear public record of the people wanting
>    that putting *their* own heads on the block, and taking the full
>    responsibility for any fall out or required remedy -- then I have
>    clean hands, and someone to point at who is completely to blame for
>    an action I advised against in the event it goes Horribly wrong.

Quit the social engineering.

[…]
> The weekend here is nearly over, and I can't keep stealing time from
> my Work customers to keep discussing this in circles next week (and
> I'm sure many others here are in the same position).
> 
> The longer we draw this out, the less testing any of it is going to
> have, the less time is going to be available to fix any shortcomings
> that we haven't so far seen, and the poorer the result that we are
> ultimately going to end up with.

Since you're low on time I'll cut to the chase.
As far as I'm concerned I now think we're down to three distinct options.

   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

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: