This PR is about implementing a plugin framework (in the conventional sense).

See #3742 for further context.

This PR introduces the following murmur config options:

• pluginmessagelimit
• pluginmessageburst

API:

• [x] Finalize API to include all requirements listed in the linked issue
• [x] Discuss the naming conventions (use custom or try to use names as close as possible to the TS API)
• [x] ~~If using TS names: Provide macros that can be used to transform the implementing function names to either follow the TS naming scheme (prefixed by e.g. ts3plugin_) or Mumble naming scheme (?)).~~
• [x] Let the API be thoroughly reviewed

Implementation:

• [x] Write (wrapper-)classes to handle plugins inside Mumble
• [x] Replace the current Plugins class in Mumble
• [x] Redirect events from Mumble to the plugin-callbacks
• [x] Write MumbleAPI for use by plugins
• [x] Write example plugin
• [x] ~~Write test-cases~~
• [x] Implement move to password-protected channel
• [x] Implement plugin update
• [x] Port to cmake
• [x] Use Poco instead of QuaZip
• [x] ~~Unload plugin's library if plugin is unloaded/shutdown via settings window~~
• [x] Make all locks non re-entrant and narrow locking scopes
• [x] Expose user's comment to plugin API
• [x] Expose user and server hash to plugin API
• [x] Expose "silence below", "speech above", "voice hold" settings to plugin API (#4419)
• [x] Explain PCM format
• [x] Include sample rate in the audio callback parameters
• [x] Rework how Strings can be passed to Mumble from the plugin so that they don't have to be static (as e.g. Rust doesn't support static strings)
• [x] Rate-limit plugin-messages (https://github.com/mumble-voip/mumble/pull/3743#discussion_r444446947)
• [x] Verify that plugin auto-updates are functional (https://github.com/mumble-voip/mumble/pull/3743#issuecomment-757375619)
• [x] Add functionality to unload a plugin from the UI
• [x] Add functionality to trigger plugin installer from UI
• [x] Store name of API functions a given resource is allocated in so that this can be printed in the "leaked memory" message (https://github.com/hbeni/fgcom-mumble/issues/81#issuecomment-780393500)

Fixes #2455 Fixes #2148 Fixes #1594 Fixes #2051 Fixes #3742 Fixes #4575 Fixes #4751

Links to comments describing changes in the API:

• 2020-08-26: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-680786524
• 2020-08-27: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-681928438
• 2020-08-30: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-683387900
• 2020-09-12: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-691518294
• 2020-09-14 https://github.com/mumble-voip/mumble/pull/3743#issuecomment-692162635
• 2020-09-15: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-692845169
• 2020-09-17: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-694392229
• 2020-09-18: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-694982997
• 2020-09-20: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-696172124
• 2020-09-25: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-698817886
• 2021-01-03: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-753608036
• 2021-01-14: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-760412898
• 2021-03-31: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-810779819
• 2021-04-14: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-819676979
• 2021-04-15: https://github.com/mumble-voip/mumble/pull/3743#issuecomment-820197431

I'm creating this issue because I haven't seen it discussed anywhere else. If there is an active discussion please post a link to it.

Mumble version 1.3 has plenty of stable features that many users value. It has a dynamic system to keep plugins up to date automatically, channel filters, per user volume controls, etc. Unfortunately, the long time period between stable releases means many users are on version 1.2.

Many users use sites like mumble.com as their download source (It's the first result in a google search for Mumble), and those only serve stable versions. Barring any regressions, a stable 1.3 release should be nothing but a good thing.

Many users are moving to alternative products (Discord) from Mumble. Part of this is discord's web client, and persistent server. Part of it is their, ugly, UI design and the fact the servers are free. But at least part of it is the features discord has and Mumble lacks, like per user volume control.

Releasing a 1.3 stable release will being many new features to the users, and shows that Mumble has an active development community. Given the long time from the 1.2 release I feel that now is the time to proceed. There are only two main questions that need to be answered:

• When was 1.2 released?
• Are there any regressions when moving from 1.2 to 1.3?

See Blocker and Critical issues.

It would be nice to have an official image of murmur for containerized deployments. I can take a crack at this if I get some guidance for what version to target (1.2.x or 1.3.x)

Given the current state of the codebase, it might be a good idea to just go and rewrite Mumble from scratch in order to get a modern codebase that is then hopefully easier to maintain, more transparent and most importantly: more accessible to new devs.

I'd like to use this issue as a platform for discussions as to how this would be tackled best, what should be looked out for (aka "best practices") and also (and this one is important) are there people out there that might be able (and willing) to help us accomplish this? The big advantage here would be that no previous knowledge of the current Mumble codebase is necessary (though of course it won't hurt), so this might be the ideal point to start contributing to the project to help us making Mumble future-proof :)

Summary

(I'll try to extract the main points from the discussion and add them here so that we'll have a nice overview of the results)

Potential contributors

(If you think that you might be able to contribute, leave a comment here and I'll add you to this list here - note that this is not binding or anything. Just to get a quick overview of how many people might be contributing)

@davidebeatrici, @Krzmbrzl, @felix91gr, @Avatat, @jplatte, @jairomer, @TredwellGit @Kissaki

This PR adds a detection mechanism that, while primitive, prevents windows hooking when a screen reader is found to be running when Mumble is executed. This is accomplished by enumerating the process list and checking for a (currently hardcoded) set of (only two right now) screen reader binaries. I know that NVDA (denoted by image name nvda.exe) is affected when Mumble loads winhooks, but I don't know if JAWS (denoted with image name jfw.exe) is. Rather than add every screen reader I know of to this list, I feel it might be better to just add them when we come across them. Note: I have not built this code yet. I am working on automating the build process since I am unable to do it on my local machine at this time, so expect errors. (I tried not to make any, but you know...) Also, I did my best to mantain formatting, though it wasn't easy. :)

Describe the bug Some strings are in English only.

Steps to Reproduce

1. Switch to Dutch or Polish (100% translated locales according to Transifex)
2. Go to Configure -> Settings... -> Audio Output

"Attenuate other users while talking as Priority Speaker" is in English despite being translated.

3. Go to Server -> Connect... -> Add New...

"Ignore" is in English, this string seems to be missing from the language files.

Expected behavior Fix hard-coded "Attenuate other users while talking as Priority Speaker" and make translating "Ignore" possible.

Desktop (please complete the following information):

• OS: Windows 10 x64 1809
• Version: Mumble 1.3.2

This has been an ongoing problem with at least 2 of our users ever sense Opus was implemented. Our workaround is to force the server to use Celt though the overall sound is not near as good.

The server is Arch Linux 64 running the latest git snapshots and this problem still exists as of Feb 10 2013.

The clients are all Windows running current snapshots.

User 1: The most frequently affected has used multiple different MICs, headsets and has recently had to switch MOBO and CPU due to a recent MOBO failure. Sadly this didn't fix the problem. The problem also persists between windows 7 and 8. Next time he is in Linux I will test if he still has the problem. I'm attaching his dxdiag and an audio sample.

User 2: Affected far less often. Has nearly the same hardware as I. The only notable difference is he is running 3 AMD GPUs vs my one Nvidia GPU. He has recently switched from an M-Audio Producer USB Mic to a Logitech G930 and still the problem persists.

User 3: Me, not affected at all, other than the ear shattering pain... Only other notable differences from User 2 I can think of is I'm using a Killer 2100 Nic “Don't judge me I got it for free.” and i'm using a Blue Yeti MIC. I haven't had this problem in windows 7 8, Arch Linux 64 and FreeBSD 9.1.

This ticket has been migrated from sourceforge. It is thus missing some details like original creator etc. The original is at https://sourceforge.net/p/mumble/bugs/957/ .

*The following attachments were added on the original item:

• https://sourceforge.net/p/mumble/bugs/957/attachment/User3.DxDiag.txt*

When I compile on a Pi4, using cmake 3.21.2 I am getting errors. After downloading mumble and then going into the mumble directory I then do

git submodule init
git submodule update

Create a build directory then proceed with the cmake (cmake .. -Dspeechd=OFF -Dplugins=OFF) I get the warnings:

  CMake Warning at src/mumble/CMakeLists.txt:458 (message):
    libsndfile is missing Opus-support -> No Opus-format recording

Followed by all of this:

-- The following features have been disabled:

 * OPUS_BUILD_TESTING, build tests.
 * OPUS_CUSTOM_MODES, enable non-Opus modes, e.g. 44.1 kHz & 2^n frames.
 * OPUS_BUILD_PROGRAMS, build programs.
 * OPUS_DISABLE_INTRINSICS, disable all intrinsics optimizations.
 * OPUS_FIXED_POINT, compile as fixed-point (for machines without a fast enough FPU).
 * OPUS_FLOAT_APPROX, enable floating point approximations (Ensure your platform supports IEEE 754 before enabling).
 * OPUS_ASSERTIONS, additional software error checking.
 * OPUS_FUZZING, causes the encoder to make random decisions (do not use in production).
 * OPUS_CHECK_ASM, enable bit-exactness checks between optimized and c implementations.
 * OPUS_FIXED_POINT_DEBUG, debug fixed-point implementation.
 * OPUS_USE_ALLOCA, use alloca for stack arrays (on non-C99 compilers).
 * OPUS_NONTHREADSAFE_PSEUDOSTACK, use a non threadsafe pseudostack when neither variable length arrays or alloca is supported.
 * OPUS_FAST_MATH, enable fast math (unsupported and discouraged use, as code is not well tested with this build option).

-- OPUS_MAY_HAVE_NEON enabling runtime detection
-- Disabling warnings for targets: opus
INSTALL TARGETS - target opus has PUBLIC_HEADER files but no PUBLIC_HEADER DESTINATION.
-- Disabling warnings for targets: celt
-- Disabling warnings for targets: speex
-- Disabling warnings for targets: rnnoise
-- Qt5 component found: DBus | Version: 5.11.3
-- Qt5 component found: LinguistTools | Version: 5.11.3
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/mumble/build

Of course the make step fails with a bunch of these:

In file included from /home/pi/mumble/3rdparty/opus/celt/arm/celt_neon_intr.c:37:
/home/pi/mumble/3rdparty/opus/celt/arm/celt_neon_intr.c: In function ‘xcorr_kernel_neon_float’:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:6740:1: error: inlining failed in call to always_inline ‘vdupq_n_f32’: target specific option mismatch
 vdupq_n_f32 (float32_t __a)
 ^~~~~~~~~~~
/home/pi/mumble/3rdparty/opus/celt/arm/celt_neon_intr.c:118:11: note: called from here
    SUMM = vdupq_n_f32(0);
           ^~~~~~~~~~~~~~

Obviously something is missing. Any help?

Kevin

Describe the bug Hi Robert, sorry to bother again, but I possibly found a regression that did not happen in your branch regarding the updater. I reproduced it with yesterdays nighly. The affected OS is at least Windows.

There are some problems, probably related:

• [x] Installation of ZIP release fails with the message like "no plugin for current OS found", despite beeing in the ZIP. (Naming Issue: partly solved by just packaging only a single binary dll/so/bundle type per target OS)
• [x] Manually trying to install the release ZIP through the plugin options yields some obscure message "invalid ZIP header" (unknown so far)
• [x] Manually extracting and then selecting the .dll does yield in a problem with the file in there not overwritable in AppData/Roaming. (probably the plugin is not unloaded in a complete or timely manner, still locking the library)
• Deleting the problematic file there and then manually selecting the .dll does work.

Steps to Reproduce

1. Download previous plugin version binary-only distribution zip: https://github.com/hbeni/fgcom-mumble/releases/download/v.0.11.0/fgcom-mumble-client-binOnly-0.11.0.zip
2. Try to install it through the plugin options
3. If sucessfull (see above description), restart mumble. The updater will pick up the more recent 0.12.0. plugin.
4. Download fails.
5. Manually installing 0.12.0 like described above does work (https://github.com/hbeni/fgcom-mumble/releases/download/v.0.12.0/fgcom-mumble-client-binOnly-0.12.0.zip).

Expected behavior I expect both the installer and updater to succesfully retrieve, unzip and install the appropriate plugin file.

Additional context For the 0.12.0 files I do not build the binarys locally, but use GitHubs Actions for it. This also introduces the new file fgcom- mumble-macOS.so into the release ZIP. Upgrading from 0.10.0 to 0.11.0 worked with your plugin-branch.

@Krzmbrzl

After macOS 10.15, Apple requires all software to be notarized before distributing. Otherwise, the user will be prompted with a scaring warning:

The process of notarizing an app can be found here: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution

In addition, useful information about notarizing apps automatically in a CI setup can be found at https://blog.zeplin.io/dev-journal-automate-notarizing-macos-apps-94b0b144ba9d

This process takes two steps:

First, we need to properly sign our app with a valid Apple Developer ID. We need to apply for one if we haven't done this before. https://developer.apple.com/programs/enroll/. A fee of $99 is charged :( for membership.

Then with that ID, we execute

export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"
codesign --force --sign "Developer ID Application: <my name>" /path/to/my.app

https://stackoverflow.com/questions/13204407/how-to-codesign-an-existing-mac-os-x-app-file-for-gatekeeper

After signing the app, we can start to get it notarized. In short, we need to

1. zip our Mumble.app container, then
2. uploading the zip file to Apple's public notarizing service. That is, passing it to xcrun altool --notarize-app -t osx -f Example.app.zip --primary-bundle-id <Bundle identifier> -u <Apple ID username> -p <Apple ID password> --output-format xml where the Bundle identifier is something located in Info.plist.
3. Then the notarizing request would be queued. We can run xcrun altool --notarization-info <Request identifier> -u <Apple ID username> -p <Apple ID password> --output-format xml to retrieve the status of this task.
4. After the notarizing is done, we need to attach Apple's certificate to the app with xcrun stapler staple Example.app

These steps are certainly not hard. But the $99 is more like blackmail. If you don't pay, your users will be scared with a warning box. This is certainly not fun, even disgusting. People are complaining about this (see https://buckleyisms.com/blog/apple-should-provide-notarization-for-open-source-apps/) as well.

There are certainly many open source apps that don't give it a damn. I think it is up the the mumble team's choice whether to pay this $99 and deliver the users a warning box-free experience.

Dear mumble developers, I think I found a bug in the echo canceller.

Basically, the way the current mumble code works is to put speaker readback samples in a queue (qlEchoFrames) in the addEcho() callback, and then in the addMic() callback take both the microphone and speaker samples and pass them to the echo canceller.

However, https://www.speex.org/docs/manual/speex-manual/node7.html#SECTION00740000000000000000 explicitly says that "It is important that, at any time, any echo that is present in the input has already been sent to the echo canceller as echo_frame." and adding a queue to the speaker samples makes them arrive after the microphone ones.

As a result, the echo canceller is only effective against periodic signals, but not for voice.

To verify that, the first commit of this pull request, https://github.com/fedetft/mumble/commit/b3aa5deb6fc15ce90726a4cb2c9d2650eed69781 adds a command line option to tap and synchronously dump pcm streams of the raw microphone, speaker readback, and processed microphone.

The result is shown in this image: https://imgur.com/a/FpeB6Mp

The top figure shows the original mumble code with only the profiling patch applied. As can be seen, the echo canceller receives the speaker readback with a high delay, I experienced up to 300ms, and is thus effective only against periodic sounds, not voice audio.

The bottom figure shows the effect of this pull request, a 20ms lead is forced by delaying the audio path, so that the echo canceller is reasonably certain to receive the data in the correct order even when callbacks are jittery.

The patch has been tested with the mixed echo cancellation on Linux with PulseAudio.

The patch fixes the issue but some more work needs to be done, in particular either the multichannel echo cancellation is broken and passes garbage data to the echo canceller, or I didn't understand how the PCM streams are passed. In any case, it does not seem to cancel echo, so there appears to be an issue, although I haven't looked it up yet.

Moreover, I could not understand if the addMic() and addEcho() callbacks can be called concurrently by multiple threads, and thus if a mutex is requred in the Resynchronizer class I added.

Via #4700, the server binaries were adapted to allow for an Opus bitrate of up to 510000 bits per second. The client on the other hand was left at a max of 192 kb/s.

While this should be more than sufficient for most users, we now adapt the limit on the client side to (in theory) be able to encode packages with that 510 kb/s bitrate limit. Outside of very specialized applications, this should be avoided though.

In order to keep the UI manageable, the respective slider now uses a logarithmic scale. This also has the benefit that optically, the default value of 40 kb/s looks pretty good compared to the max. possible value and therefore novice users hopefully keep that value at its default.

Fixes #5989

Checks

• [x] My commits follow the commit guidelines

Description

The bitrate in the Registry and in the client gets overwritten after applying new settings in the options.

Steps to reproduce

close mumble setting to a higher bitrate then the settings allowed: HKEY_CURRENT_USER\Software\Mumble\Mumble\audio - quality to e.g. 529000 close regedit and start mumble verify with the audio statistics go to the options with or without changing somethings and click apply or ok in the audio statistics is now the value that was in the settings e.g. 192000 close mumble and open regedit the value in the registry is now changed too

Mumble version

1.4.287

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

Additional question: Why do I have only 300kbit/s in the audio statistics after setting the value to 529000?

Relevant log output

<W>2022-12-13 15:03:04.969 AudioInput: 529000 bits/s, 48000 hz, 480 sample
After clicking OK/Apply:
<W>2022-12-13 15:03:11.132 AudioInput: 192000 bits/s, 48000 hz, 480 sample

Screenshots

No response

Greetings everybody,

As stated before, I am going to try to improve the accessibility of Mumble. This is rather hard for me, because I am limited to the accessibility options provided for Linux - specifically Ubuntu 22.04 LTS with Gnome Desktop Environment. Furthermore, I am not using any accessibility tools myself so I might miss or misinterpret a thing or two. Nonetheless, I am going to try to improve what I can and Qt lets me.

This merge request is supposed to contain all the changes I make as separate commits. It also contains a ToDo List further down, which I will also try to keep accessible for screen readers. Please feel free to add comments for additions to the ToDo list, or other general feedback. Please note that parts of the ToDo list might be impossible to solve due to how the Qt Framework works, or might be specific to my screen reader configuration.

Note: These commits are currently not part of any official Mumble release. They probably will not make it into Mumble before the 1.5 series is released. If you want to try out the changes in this branch, you will have to either compile the branch yourself, or go through the cumbersome GitHub user interface to navigate to the build pipeline artifacts of this merge request.

For the following ToDo list I went through Mumble with a screen reader using only the keys TAB, Shift-TAB, Arrow Keys, Space, and Enter. It is clear that Mumble is very inaccessible in certain places.

I have since updated and adapted the ToDo list with respect to feedback I have gotten here on GitHub. The current version is from December 2nd.

Start of the ToDo list.

In the "Audio Tuning Wizard": General:

• [x] The "Next" and "Back" buttons read out the ">" (greater than) and "<" (less than) symbols, which is confusing.
• [x] Header texts are not read when flipping pages in the wizard using "next" and "back" buttons.

First page of the "Audio Tuning Wizard":

• [x] There is a missing word in the sentence "The settings are only once this wizard has been completed".

Device Selection page:

• [x] The first combo box is automatically selected. None of the info text is read.

Volume Tuning page:

• [X] The screen reader repeats the raw slider value when it is changed which has absolutely no informative value.

Voice Activity Detection page:

• [x] The slider is focused first, with no indication that there are radio boxes above.
• [x] The general fact that there are radio buttons, which switch between the activation modes is not very well explained.
• [X] The screen reader repeats the raw slider value when it is changed which has absolutely no informative value.
• [x] The ":" symbol is read on the first radio button.
• [x] The button to assign a short cut for Push to Talk does not inform the user that it can be used to reassign the Push to Talk Key when using a screen reader. It says "PTT-Shortcut Push Button", but the label says "No buttons assigned."
• [x] When selecting "high contrast graphics" in the previous page, the "Signal-To-Noise ratio" slider is pretty much unusable even for seeing users.

Note: The accessible slider values should, in theory, be set to a better and more understandable value. However, Orca refuses to read anything but rare Slider values. Hopefully this is not the case for other screen readers or fixed in Orca (if it is actually a bug).

Quality & Notifications page:

• [x] The quality setting radio buttons are read, but their extensive descriptions are not read.

Edit Shortcut Dialog:

• [ ] There is no indication whether or not the dialog is listening for input

In the Main Mumble Window:

• [x] The Channel and Users tree does not specify, if a selected item is a channel or a user.
• [ ] The log window is not accessible. No individual text items are selectable and are therefore not read. (Issue #5811) (Note: New chat messages are read, if the Mumble internal Text To Speech option is enabled)
• [ ] The log window lets the user select links (<a>) to channels and users using TAB, which are not read as well as very unhelpful anyway. These should not be selectable.
• [x] There is no accessible way to determine, if the current Channel and Users tree is being filtered or not.
• [X] The autocomplete in the chat bar is preventing an easy TAB navigation. (Issue #5811)
• [x] The status effects for example "muted", "deafened" or "channel requires permission" are not accessible in the Channel and Users tree. (Issue #2292)
• [x] The user comment is not accessible for screen reader users. (Issue #2292)
• [ ] There is no way to move users without a mouse. (Issue #4642)
• [ ] The Local Volume Adjustment slider is not read.

In the Mumble Server Connect Dialog:

• [x] The button "Add New..." is selected first. There is no indication that there is a public server list loading.
• [x] Screen readers should state how this dialog is supposed to work. There are two methods: Searching the public server list and adding custom servers using their IP address. (Issue #1337)
• [x] The selected item in the server list is not read when TABBED into.
• [x] Favorites are not read.
• [x] The "Connect" button is not reachable with forward-TAB.
• [x] The optional password dialog is completely inaccessible for screen reader users. (Issue #5811) (Note: I can not reproduce this issue with the current branch)

Certificate Alert:

• [x] The fingerprint of the cert is very long and read first before any instruction on what the ramifications of the situation are.

In the Server Information Dialog:

• [ ] Only the TCP Control statistics are read with no indication that there is more text above. (Note: This will require a creation of a brand new custom QWidget, because Qt has no way of making simple QLabel lists accessible)

In the Client Information Dialog:

• [ ] Nothing is accessible at all. (Note: This will require a creation of a brand new custom QWidget, because Qt has no way of making simple QLabel lists accessible)

In the Access Token Dialog:

• [x] The screen reader tells us that there is a list with N entries, but the items are never read.

In the Recorder:

• [x] The "target directory" text box reads all the options listed in its tool tip. This is not very understandable by just hearing the special characters.
• [x] When starting the recording, the stop button should be selected automatically for an easy way to stop the recording. Currently a disabled control element is selected automatically.
• [x] The labels in "Output" are somehow not correctly used to describe the fields.

In the Certificate Wizard: General:

• [x] The "Next" and "Back" buttons read out the ">" (greater than) and "<" (less than) symbols, which is confusing.

Certificate Authentication page:

• [ ] The current certificate should be read.
• [ ] The radio buttons should be selected first, otherwise there is no indication that there are radio buttons at all.

New Certificate page:

• [x] Email is selected first. The info text is not being read.
• [x] The tool tips contain "(e.g. John Doe)" but it should rather be read as "for example John Doe".

Replace Certificate page:

• [x] No text is read.

Export Certificate page:

• [x] None of the text is read. The certificate details should be read, before the "Export to" is selected.

In the Mumble Settings: General:

• [ ] Screen reader says "Configuration Categories", but does not read the specific category that is being selected.
• [ ] TAB first cycles to the buttons. It should probably first cycle through the actual settings of the page.
• [ ] Sliders should read the semantic value with suffix instead of plain slider values.

Audio Input page:

• [ ] Transmit mode combo box is not read at all.
• [ ] "Amplitude/Signal to Noise" radio buttons and "Low delay mode" checkbox are only selectable after the "Audio Processing" section, which is confusing.
• [ ] The "silence below", "speech above" slider values are completely useless.
• [ ] The "Noise Suppression" sub section is being read as "Audio Processing"
• [ ] Noise Suppression radio boxes should select the active option first instead of "both", which is unhelpful without context.
• [ ] "Misc" selects the "nothing" combo box which is confusing.
• [ ] The "Misc" button selection order is all over the place.

Audio Output page:

• [ ] Interface combo boxes are not read at all.
• [ ] Selection order of elements is all over the place.

User Interface page:

• [ ] Selection order of elements is all over the place.

Shortcuts page:

• [ ] The shortcut tree is completely inaccessible for screen reader users. (Issue #2293)

Messages page:

• [ ] All of the checkboxes in the message type list are completely inaccessible without a mouse. (Issue #2972)

Plugins page:

• [ ] All of the checkboxes in the plugin list are completely inaccessible without a mouse.

End of the ToDo list.

Context

When using mumble for remote working we sometimes have to local mute people that sit in the same room to avoid hearing them twice.

Unfortunately this setting is sticky, causing them to still be locally muted when they rejoin the server a while later.

Description

It would be great if it would be possible to temporarily local mute someone until they disconnect from the server

Mumble component

Client

OS-specific?

No

Additional information

No response

Context

Server administrators can currently suggest certain client properties, such as the minimum client version or that the client should have positional audio and/or push-to-talk enabled.

Description

The suggestions currently only show as a small text message in the chat bar. Given how noisy the chat bar is (in general) these messages will most likely be missed and therefore ignored.

Instead, these messages should be shown as messageboxes (if the conditions are not already fulfilled)

Mumble component

Client

OS-specific?

No

Additional information

Somewhat related: #1806