The new script is more powerful and in particular can compare across different branches.
Furthermore, it no longer only considers merge commits. Instead, all commits are screened individually, which should make the script be much more suitable for situations in which a PR introduces multiple changes that are not well described by a single commit message (the merge commit's one).
Previously, audio cues would play and continue to play no matter what. If very long sound samples were used, they would play longer than the user sends audio (regardless of PTT or VA) and they could even play over each other.
Fixes#1671
The new script is more powerful and in particular can compare across
different branches.
Furthermore, it no longer only considers merge commits. Instead, all
commits are screened individually, which should make the script be much
more suitable for situations in which a PR introduces multiple changes
that are not well described by a single commit message (the merge
commit's one).
The name AudioOutputUser is a legacy one, or, in case it is meant as
"user of the audio output API", at least slightly misleading.
Since both AudioOutputSpeech and AudioOutputSample inherit AudioOutputUser
it makes more sense to name it as what it actually is: A buffer wrapper.
Previously, audio cues would play and continue to play no matter
what. If very long sound samples were used, they would play longer
than the user sends audio (regardless of PTT or VA) and they could
even play over each other.
The commit introduces a member in AudioInput to save the last
sample played for audio cues. When switching from talking to
non-talking or vice versa, it first stops the previously
played cue.
Fixes mumble-voip#1671
AudioOutput keeps track of users and their speech, as well as samples
in qmOutputs. The mix() method will iterate over them and append all
completed outputs to a list 'qlDel'. This list is then - outside
of any synchronization - used to remove entries from qmOutputs.
Previously, other methods were also deleting from qmOutputs directly from
other threads. In rare conditions, when the output just finished and is
added to qlDel and then additionally manually deleted, the pointer could be
subject to a double delete.
This commit tries to mitigate the problem and overhauls the output
deletion by introducing a singal and a slot, delegating the deletion
to the audio thread event queue. A new AudioOutputToken class is
introduced, to prevent direct access to audio buffer pointers.
The overlay doesn't work on ARM Macs, so we disable it on these machines. However, the CMAKE_SYSTEM_PROCESSOR variable doesn't always hold the target architecture and as it turned out it contained the host arch on our M1 macOS builder, causing the overlay to be disabled for our x86 macOS binaries that were cross-compiled from our M1 machine.
Therefore, we now leverage the system we also use to detect the target architecture for passing it as a macro to our code.
The overlay doesn't work on ARM Macs, so we disable it on these
machines. However, the CMAKE_SYSTEM_PROCESSOR variable doesn't always
hold the target architecture and as it turned out it contained the host
arch on our M1 macOS builder, causing the overlay to be disabled for our
x86 macOS binaries that were cross-compiled from our M1 machine.
Therefore, we now leverage the system we also use to detect the target
architecture for passing it as a macro to our code.
We've been receiving quite a few reports about the program seemingly freezing, such as
forums.mumble.info/topic/14467-14-conflict-with-flight-control-rudder-pedals.
Turns out there are HID devices, namely advanced controllers, that constantly send packets.
The reason behind the behavior is probably to prevent games from losing track of the physical state.
Qt's event dispatcher blows up and consumes all resources, leading to:
QEventDispatcherWin32::registerTimer: Failed to create a timer (The current process has used all of its system allowance of handles for Window Manager objects.)
As a result, the UI completely freezes due to events not being processed anymore.
This commit fixes the issue by using an SPSC (Single Producer Single Consumer) queue.
The event loop and 20 ms timer are removed. The latter was strictly used for XInput and G-keys polling.
Both backends still work, potentially better than before: no more polling!
Whenever a HID message is received, the relevant code is executed.
Fixes#5631
We've been receiving quite a few reports about the program seemingly freezing, such as
https://forums.mumble.info/topic/14467-14-conflict-with-flight-control-rudder-pedals.
Turns out there are HID devices, namely advanced controllers, that constantly send packets.
The reason behind the behavior is probably to prevent games from losing track of the physical state.
Qt's event dispatcher blows up and consumes all resources, leading to:
QEventDispatcherWin32::registerTimer: Failed to create a timer (The current process has used all of its system allowance of handles for Window Manager objects.)
As a result, the UI completely freezes due to events not being processed anymore.
This commit fixes the issue by using an SPSC (Single Producer Single Consumer) queue.
The event loop and 20 ms timer are removed. The latter was strictly used for XInput and G-keys polling.
Both backends still work, potentially better than before: no more polling!
Whenever a HID message is received, the relevant code is executed.
A bounded single-producer single-consumer wait-free and lock-free queue written in C++11.
It is going to be used for the Windows implementation of global shortcuts.
Since newer versions of libsndfile now link to the system-wide installed Opus version (on Linux distros), there would be a conflict between symbols defined in the system-wide installation and the self-built (bundled) Opus library.
This, as it turned out, can lead for instance to failing assertions due to pointer identities no longer holding because e.g. a function from the self-built Opus version ends up calling a sub-function from the system-wide Opus installation instead. This is also the root cause for the infamous "Opus crash" or "Audio wizard crash".
In order to avoid these issues, we don't ship a bundled Opus version anymore and instead make it a build prerequisite to have Opus installed on your system.
Fixes#5302
Since newer versions of libsndfile now link to the system-wide installed
Opus version (on Linux distros), there would be a conflict between
symbols defined in the system-wide installation and the self-built
(bundled) Opus library.
This, as it turned out, can lead for instance to failing assertions due
to pointer identities no longer holding because e.g. a function from the
self-built Opus version ends up calling a sub-function from the
system-wide Opus installation instead. This is also the root cause for
the infamous "Opus crash" or "Audio wizard crash".
In order to avoid these issues, we don't ship a bundled Opus version
anymore and instead make it a build prerequisite to have Opus installed
on your system.
Fixes#5302
This commit ensures that we first try all names for the different base paths in turn, before we fall back for a generic search for that lib based only on the given name.
Otherwise, e.g. the system Opus library could be used instead of the bundled version compiled together with Mumble.
This commit ensures that we first try all names for the different base
paths in turn, before we fall back for a generic search for that lib
based only on the given name.
Otherwise, e.g. the system Opus library could be used instead of the
bundled version compiled together with Mumble.
Since newer Opus versions appear to cause crashes under some
circumstances, we downgrade our Opus submodule to point to the latest
stable release, which is v1.3.1 from 2019.
We will only be able to upgrade again, once the underlying issue causing
the crashes has been identified and fixed.
Fixes#5302
Currently translated at 100.0% (2106 of 2106 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: John Doe <thraex@numericable.fr>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/fr/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2106 of 2106 strings)
TRANSLATION: Update Chinese (Simplified) translation
Currently translated at 100.0% (2106 of 2106 strings)
Co-authored-by: Eric <hamburger1024@duck.com>
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: deluxghost <deluxghost@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/zh_Hans/
Translation: Mumble/Mumble Client
When packaging is not enabled, do not assert that the install paths are
relative. This fixes issues with live ebuilds in Gentoo.
This partially reverts 703af920d8
Signed-off-by: Kenton Groombridge <concord@gentoo.org>
And while we're at it, give it a different name that better describes what this function is actually doing (spoiler: it is not only checking whether the given user is part of the specified group).
And while we're at it, give it a different name that better describes
what this function is actually doing (spoiler: it is not only checking
whether the given user is part of the specified group).
This MR contains two changes:
1. Clear the priority speaker flag on channel switch
2. The priority speaker should either be saved/loaded or cleared when a user enters/leaves a channel #5334)
Change how the temporary channel mute/deaf permission check is performed. Also: Allow priority speaker in temporary channels.
Fixes#5334Fixes#1877
FEAT(server): Flag bot connections
This commit introduces a new flag that connecting clients can use to
tell the server they are connecting to that they consider themselves bot
clients. This information can then be used (as is the case for the
official server implementation) to e.g. correct the reported user count
on the server to only include "real" clients - aka: no bots.
Fixes#5461
Closes#1737Closes#1830
This MR contains two changes:
Add the "Channel Filter" toggle action to the menu bar especially for use in the minimal view as specified in
Missing context menu entry to toggle channel filtering in minimal view. #1737
Implement a "channel pin" flag as specified by
Show channel when filtering #1830. I was almost done when I realized that @hacst already had a merge request going some time ago... (Add 'always visible' channels to filtering mechanism #2612) We implemented this in a very similar way and I added them as a co-author.
