This is a read-only archive of the Mumble forums.

This website archives and makes accessible historical state. It receives no updates or corrections. It is provided only to keep the information accessible as-is, under their old address.

For up-to-date information please refer to the Mumble website and its linked documentation and other resources. For support please refer to one of our other community/support channels.

Jump to content

Murmur not converting opus to celt for backward compatibilit


bbosen
 Share

Recommended Posts

I am using murmurd version "1.2.12-lubuntu" to handle all different kinds of Mumble clients. Most of my users now have Mumble V1.3.0 clients, but there are still a lot of them using old Mumble V1.2.3, and I also have several using Android's "Plumble" client. At least one other person uses some kind of Mumble client on an iPhone under IOS.


Because some of these diverse Mumble clients (notably the old V1.2.3 ones on Linux) are incompatible with the newer "Opus" CODEC, I never want the murmurd server to force use of the "Opus" codec. In fact, I am assuming (and hoping) that when murmurd receives opus-encoded audio, it can decode it and re-encode it using celt or something that can be understood by older versions of the Mumble client. This, I assume, is the underlying mechanism for any backward-compatibility that ought to allow old Mumble clients to communicate with new Mumble clients and vice versa.


Accordingly, I have been experimenting with the "mumble-server.ini" file in an attempt to completely eliminate all use of that opus codec from my diverse environment at all times. I am having a lot of trouble with that.


My goal is, of course, for everybody to be able to hear and speak with everybody else. Sometimes that works and sometimes it does not. When it does NOT work, the usual symptom is that people using older versions of Mumble hear painfully distorted, completely bewildering noise when other people, using a newer version of Mumble, transmit audio.


I think this is because the newer versions of Mumble are encoding their audio with the opus codec, which people with older versions of Mumble are not equipped to decode, resulting in the horrible, painful, ear-splitting noise.


I guess everything works correctly for my entire community about 40% of the time. However, for some unknown reason, it is VERY commonplace for users of the old Mumble version 1.2.3 to hear noise so awful it makes them sick when newer Mumble versions transmit audio.


I am going crazy trying to figure out any pattern in this. I can only conclude that SOMETIMES my murmurd server is filtering out the opus-encoded audio, and at other times it is not doing so. I don't know why.


As I have experimented with the "mumble-server.ini" file, I have concentrated on the definition of the "opusThreshold" attribute. The associated comment documenting use of that attribute in the file says:


"# Amount of users with Opus support needed to force Opus usage, in percent.

# 0 = Always enable Opus, 100 = enable Opus if it's supported by all clients."


I tried setting "opusThreshold" to 100, thinking that the result would permanently eliminate opus encoding for my users, since a significant percentage of my traffic does NOT use opus.


That works for me about 40% of the time.


I also tried setting "opusThreshold" to 99, just to see if it would work better. No change. It still works for me only about 40% of the time. Most of the time (about 60% or so), a lot of my users are still hearing horrible, painful, ear-splitting noise from senders that (I think) are using opus.


When this works correctly, it seems to work for ALL users, exactly as I hoped. When it does not work correctly, it fails for all users of older versions of Mumble. They all fail together for awhile then, sometime later, they all start working again.


Can anybody help me understand the logic by which murmurd figures out the percentage of opus users? For example, what is the time span sampled to calculate this percentage? Does it look back in time for 10 seconds, 10 minutes, an hour, a day, a week, or since program installation as it determines the percentage of users with Opus support? Is there some way to reset this time span or some other, more reliable way to persuade murmurd to eliminate opus-encoded transmissions?


And is my understanding correct that an appropriately configured murmurd ought to decode murmur-encoded audio and then re-encode it with a legacy CODEC like "celt" in order to solve this problem?


I am wondering if I am tripping on some program bug in murmurd as it tries to determine if and when it ought to change opus-encoded audio into celt-encoded audio.


Thanks for any help you can offer.

Link to comment
Share on other sites

  • Administrators

The Mumble server does not decode and reencode audio data. It just routes the audio packets to targets.


If available to enough users as per threshold setting the Opus codec will be used. If you set it to 100 and the first user that connects does not support Opus, the server will advertise a switch to an older baseline, fallback codec.


CELT 0.7.0 is the baseline codec that should be supported by all 1.2 and 1.3 clients. Debian did ship a broken/incompatible version for a while quite some time ago though.


1.2.3 is 8 and a half years old. There have been several bugfix and security fix patch releases for 1.2 (although I don't know if any of those are for client-side security issues and how much so). I understand the desire to make it work, but I don’t see putting that much effort into that worth it. Opus is a superior codec in many ways, and we are likely to drop the baseline support for CELT in 1.4. These users should upgrade their client versions.


The CELT 0.7.0 fallback should work automatically. No idea why it does not for you(r users).

Link to comment
Share on other sites

Thank you very much kissaki. Your explanation helped me figure out a process that now has everything working reliably. I had misunderstood the role of the murmurd server in this situation.


Some of my old mumble clients are evidently misbehaving in the way they participate in the CODEC reporting and negotiation process. (The misbehaving old mumble Mumble 1.2.3 clients are all running on PcLinuxOs, which is a distant, very conservative derivative of Debian LINUX. Although it is problematic because it only supports the ancient 1.2.3 version of Mumble, PcLinuxOs has other redeeming and compelling features that make it extremely useful to about 40% of my community.)


However, I have found at least one old Mumble client that properly reports its reliance on the "CELT" CODEC. So long as that client is used periodically, murmurd "gets the message" appropriately and advises all of the newer clients to fall back to the celt CODEC. At that point everybody can communicate with everybody else to my satisfaction. This solution lasts long enough for me to manage. Problem solved.


I look forward to the day when I can demand that all of my users upgrade to newer versions of Mumble, but that day has not yet arrived for me.


; )

Link to comment
Share on other sites

 Share

×
×
  • Create New...