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

When Mumble V1.2.3 clients talk to Mumble V1.3.0 clients


bbosen
 Share

Recommended Posts

I use Mumble with Linux Air Combat for interplayer communication. Most of the pilots using Linux Air Combat have happily been using an older version of Mumble (V1.2.3). Recently I updated my development and test environment and got newer Mumble 1.3.0, which seems to be the current version as of this writing in July of 2019.


Two or more users with matching client versions can speak with one another without problems, whether they match up with old version 1.2.3 or with new version 1.3.0.


However, when a user with the new version speaks, everybody monitoring that channel with the older version hears HORRIBLE, loud, scratchy, staticky, grinding noises that make my ears bleed.


Can I fix this with an updated Murmur server or something? Is this a known problem due to some protocol change?


Thanks for any insight you can give!

Link to comment
Share on other sites

Further info: Testing confirms that users of older version 1.2.3 hear this violent distortion when audio comes in from the new Mumble V1.3.0 clients. However, users with the new V1.30 client do NOT hear that distortion when audio comes to them from the older clients.


Accordingly, the new version (V1.30) can exchange audio with V1.30 peers in both directions and can correctly HEAR incoming audio from the older version.


The problem is that users with the older version suffer terribly whenever anybody with the new version sends audio. The loud, distorted audio is unintelligible and terribly painful. It sounds like an acoustic weapon from outer space.


I have a community of users equipped with the older version and I am sure that this migration is going to be difficult unless there is some adjustment that can be made.


Could this be related to conflicting codecs in use? Could this be resolved by some configuration adjustment by the players or at the server?


Thanks!

Link to comment
Share on other sites

One last detail in case it matters: For my Mumble Server I am using murmurd version 1.2.12 on a current version of lubuntu.


Also, I found the following documentation about the way Mumble has evolved to use increasingly sophisticated codecs:


Older Mumble versions use Speex for low bit rate audio and CELT for higher quality audio while new Mumble versions prefer Opus for all audio. When multiple clients with different capabilities communicate together the server is responsible for resolving the codec to use. The clients should respect the server resolution if they are capable. If the server resolves a codec a client doesn’t support, that client is free to use any codec it prefers. Usually this means the client will not be able to decode incoming audio, but it can still send encoded audio out.The CELT bitstream was never frozen which makes most CELT versions incompatible with each other. The two CELT bitstreams supported by Mumble are: CELT 0.7.0 (CELT Alpha) and CELT 0.11.0 (CELT Beta). While CELT 0.7.0should technically be supported by most Mumble implementations, some servers might be configured to force Opus. Mumble has had Opus support since 1.2.4 (June 2013) so it should be safe to assume most clients in use support this now.


Since my legacy players are using release 1.2.3, they must be limited to just the "speex" and "celt" codecs. Accordingly, they probably cannot decode the audio from version 1.3.0's "opus" codec. Perhaps that is the cause of my problem. Is there some way to configure standard version 1.3.0 Mumble clients to use those legacy "speex" or "celt" codecs? Or is there some way to configure the server to demand the speex codec all the time?

Link to comment
Share on other sites

More details:


Digging into Mumble's "murmur" server configuration docs I found this:


"opusthreshold


opusthreshold is a number between 0 and 100, which specifies a percentage of users on the server supporting the Opus codec before the entire server mandates opus is used. It defaults to 100, so that any non-Opus supporting client connecting will cause the entire server to fall back to CELT. This is a safe default, to avoid users not being able to hear other users."


I confirm that my murmur server (version 1.2.12 on a current version of lubuntu) is configured, via its /etc/mumble-server.ini file, to avoid demands for the opus codec because the "opusthreshold" attribute is explicitly set to "100" as described above. (I also tried configuring the murmurd server to simply default to that "100" value. No change.)


The documentation seems to indicate that this "opusthreshold" attribute was created to solve my problem, but it does NOT work according to my understanding of what is published (at least with version 1.2.12 of murmurd which I am using on lubuntu).


One possibility that occurs to me is that the fallback to the "CELT" codec may still yield certain incompatibilities. This suspicion is triggered by this bit of documentation:


"The CELT bitstream was never frozen which makes most CELT versions incompatible with each other. The two CELT bitstreams supported by Mumble are: CELT 0.7.0 (CELT Alpha) and CELT 0.11.0 (CELT Beta)."


Since Mumble has limited its CELT choices to "0.7.0" and "0.11.0", can anybody confirm that those two are mutually interoperable? Are there any developers or experts with further insight?


Thanks!


-bbosen-

Link to comment
Share on other sites

  • Administrators

Hello


CELT 0.7 is the fallback interoparability codec. 1.2 and 1.3 are fully compatible with that.


1.2.3 introduced CELT 0.11, and so 1.2 clients above 1.2.3 can talk with 1.3 clients with CELT 0.11 as well (and will do so automatically).


1.2.4 introduced Opus. So 1.2 clients later than 1.2.4 can talk with 1.3 clients with Opus.


I only skimmed/read the last part. So excuse me if I missed anything in your numerous and long posts. :) Feel free to ask again if I missed other questions.

Link to comment
Share on other sites

Kissaki: Thanks for your attention. You wrote:


"CELT 0.7 is the fallback interoperability codec. 1.2 and 1.3 are fully compatible with that."


This implies that my old 1.2.3 clients should be able to use CELT 0.7 for operational compatibility with the new 1.3.0 client


"1.2.3 introduced CELT 0.11, and so 1.2 clients above 1.2.3 can talk with 1.3 clients with CELT 0.11 as well (and will do so automatically)."


Your phrase "ABOVE 1.2.3" implies that my 1.2.3 client cannot use CELT 0.11 to communicate with the new 1.3.0 client, restricting interoperability to just CELT 0.7.


"1.2.4 introduced Opus. So 1.2 clients later than 1.2.4 can talk with 1.3 clients with Opus."


This also implies that my 1.2.3 clients are too old to use Opus interoperate with the new 1.3.0 client.


All of this indicates that the "fallback interoperability codec" (CELT 0.7) is present in my old clients and in the newest ones too. Accordingly, there ought to be some way to configure my clients or servers for interoperable communication using CELT 0.7. Nevertheless, none of my attempts to do so have been successful, resulting in loud, unintelligible noise instead.


Can a codec mismatch cause the receiving client to make loud, unintelligible noise?


Do all versions of the murmur server fall back to that 0.7 interoperability codec as you describe? Or are there some early versions that do not? Is my murmur version 1.2.12 the appropriate version for this interoperability?

Link to comment
Share on other sites

  • Administrators

Sorry, I meant 1.2.3 and above for 0.11.

 

Can a codec mismatch cause the receiving client to make loud, unintelligible noise?

 

Yes


Codec negotiation happens automatically and transparently. Apart from the opusthreshold setting that can be set by the server administrator, neither the user nor the server administrator should have to set up anything, or can even do so.


If clients all are capable of Opus, Opus should be in effective use. Once an older client connects that does not support Opus, the clients all should be automatically be switching to CELT 0.11 if they all support it (all >= 1.2.3), or CELT 0.7 if they don't.


I remember some years ago a Linux distribution, I think it was Debian, for some reason shipped (or thought about shipping?) an incompatible codec version. I am not sure how graceful they handled it, but I think to remember that it caused or could cause issues. Basically they broke the codec contract. Which baffled me. I can't give you specifics though without searching.

Are you using Debian or an older Linux distribution?

Link to comment
Share on other sites

Yes. I am using a Debian derivative Linux distro. Although my version is fairly recent (Mar2019) their version of Mumble has not been updated in several years, and this particular distro is conservative about component upgrades. It wouldn't surprise me to find that they haven't updated those libraries in a long while. I bet that's the problem. THANKS VERY MUCH for helping me get to the bottom of this!

Link to comment
Share on other sites

  • Administrators

Derivatives may or may not include upstream issues. I don't think it was ever a problem on Ubuntu AFAIK for example.


Unfortunately I do not know if they used some adjusted codec naming e.g. you could see in Mumbles (server) information dialog.

Probably not as the celt library is a separate, shared package on Linux distros, which is why we depend on it and use the broken version in the first place.


Anyway, you at least have something to analyse/check further. :)


You're welcome. Good luck on finding a solution for your use case.

Link to comment
Share on other sites

I have decided to abandon my long-beloved, stable, stodgy LINUX distro for access to more updated applications like Mumble (and many others). I will miss dear old PcLinuxOS! But my experiments with Manjaro indicate it is a better answer to my current needs. I am converting my entire development lab (14 machines). This will take awhile....


Thanks for helping me make this painfully big decision!

Link to comment
Share on other sites

 Share

×
×
  • Create New...