Add Local- and Server- buffererror detection in CChannel

[pgScorpio]

What is the current behaviour and why should it be changed?

Adding JitterBuffer error detection for both client and server side errors in CChannel.
(Preparation for issue #2524. As discussed in issue #2524)
At this moment there is only a jitterbuffer error detection for the client side, implemented in CClient.
A better way of detection can be implemented in CChannel and also the protocol will be extended (fully backwards compatible, no new messages.) to provide jitterbuffer error flags for both client and server on the client side.

Describe possible approaches

See the discussion in issue #2524.
Pro's:

• Client can now indicate Local buffer underuns as well as Server buffer underruns, making manual buffer setting easier for most users.
• Fully backwards compatible.

Cons:

• Still no server-side buffer underrun indication when connected to old servers (But in this case the client will hide the Server Jitter Buffer Status LED.).

We will use the PROTMESSID_JITT_BUF_SIZE message with buffersize=0 to send buffer underrun information from server to client. (The other way around would also be possible, but I don't see any use for it at the server side.)
The server will always explicitly send a "buffer underrun" message during connection setup, so the client will know that the server supports this new message (since old servers never send it.).
CChannel will have Get-And-Reset functions for both flags for use by CClient.

Has this feature been discussed and generally agreed?

See the discussion in issue #2524.

[hoffie]

Client can now indicate Local buffer underuns as well as Server buffer underruns, making manual buffer setting easier for most users.

Sounds useful to me.

Still no server-side buffer underrun indication when connected to old servers (But in this case the client will hide the Server Jitter Buffer Status LED.).

That's not an issue, IMO. :)

We will use the PROTMESSID_JITT_BUF_SIZE message with buffersize=0 to send buffer underrun information from server to client.

I'm not entirely convinced whether it's better to re-use and overload this existing protocol message (it's related, but the original meaning is different) or whether to add a new protocol message for this (this is not a problem for backwards-compatibility; changing existing messages would be). I'd tend towards the latter.

(The other way around would also be possible, but I don't see any use for it at the server side.)

It would allow server-side client audio quality monitoring. I wouldn't add it right now, but I also wouldn't rule out that this may ever be interesting.

In the end, the decision about adding this feature is likely an assessment of the usefulness of the feature vs. the cost (additional protocol message/parsing, UI space). Let's way what others say. #2524 had some tendencies on the "no" side.

[pgScorpio]

@hoffie

I'm not entirely convinced whether it's better to re-use and overload this existing protocol message (it's related, but the original meaning is different) or whether to add a new protocol message for this (this is not a problem for backwards-compatibility; changing existing messages would be). I'd tend towards the latter.

I'm not convinced what would be the benefit of introducing a new protocol message. Since it's 100% related to Jitterbuffer size (Size too small. Though we just could rename the message, removing the _SIZE if that seems more logical to you.).

It would allow server-side client audio quality monitoring. I wouldn't add it right now, but I also wouldn't rule out that this may ever be interesting.

If we are thinking about having that server side functionality in the future wouldn't it be wiser to already implement the client to server message too? That would make backwards compatibility easier in the future.

[gilgongo]

Is there an example of something a user could do as a result of knowing about errors for both client and server? It's hard to see better stats as being much of a priority otherwise.