You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I'm aware the decoders/encoders are only semi-functional, when using the command-line demo to access a server, I've found that you regularly get NotImplemented exceptions because it's trying to use the preferred CELT encoder, rather than falling back on Speex.
This is for two reasons - one, I think you're creating the codec thread before you've got a ServerSync message (so you don't yet know the appropriate codec to use) and two, there's no default value specified for the TransmissionCodec in the BasicMumbleProtocol class.
One fix is to re-order your codecs in SpeechCodecs.cs - give Speex the zero value, then it will fall back on that codec as it should. You could then start/stop the encoding thread and create a new encoder when required on a ServerSync or ServerConfig message, which resolves the issue of your codec being initialised early.
The text was updated successfully, but these errors were encountered:
no default value specified for the TransmissionCodec in the BasicMumbleProtocol class.
That's a good point, the codec should probably be nullable:
public SpeechCodecs TransmissionCodec? { get; private set; }
and then the handler for received packets should probably drop packets if it doesn't have a codec set yet (this should never happen, as the server is meant to send sync before any voice):
private void EncodingThreadEntry()
{
IsEncodingThreadRunning = true;
while (IsEncodingThreadRunning)
{
if (TransmissionCodec.HasValue) {
var packet = _encodingBuffer.Encode(TransmissionCodec);
if (packet != null)
Connection.SendVoice(new ArraySegment<byte>(packet));
}
}
}
I think these two changes would resolve all of the problems with default codecs. Ultimately the codec choice is up to the server, and CELT support is required by all mumble clients so these errors may keep happening if the server chooses CELT (which it is always allowed to do).
One fix is to re-order your codecs in SpeechCodecs.cs
This definitely isn't safe! The values in SpeechCodecs are copied from the mumble source and can't change (see here)
N.b.
I'll leave this issue open to remind me to implement these changes, but I won't be working on them anytime soon. If you would like to test these changes I will be happy to accept a PR though :)
While I'm aware the decoders/encoders are only semi-functional, when using the command-line demo to access a server, I've found that you regularly get NotImplemented exceptions because it's trying to use the preferred CELT encoder, rather than falling back on Speex.
This is for two reasons - one, I think you're creating the codec thread before you've got a ServerSync message (so you don't yet know the appropriate codec to use) and two, there's no default value specified for the TransmissionCodec in the BasicMumbleProtocol class.
One fix is to re-order your codecs in SpeechCodecs.cs - give Speex the zero value, then it will fall back on that codec as it should. You could then start/stop the encoding thread and create a new encoder when required on a ServerSync or ServerConfig message, which resolves the issue of your codec being initialised early.
The text was updated successfully, but these errors were encountered: