Due to RNNoise being unmaintained and the library's code being in very poor shape, this commit excludes the RNNoise feature from Mumble by default and discourages its use.
The library contains Opus and CELT symbols (probably due to copy&paste of code) that can end up being called from Opus instead of its own versions of these functions. This can lead to completely unforeseen behavior, including crashes.
An example of this is as of writing this, enabling RNNoise on macOS leads to a crash of Mumble pretty much as soon as it starts up with an "invalid instruction" error. The reason being that part of RNNoise's implementation of one of Opus's symbols contains a code path that produces an invalid instruction in optimized builds (and a segfault in debug builds) and this code path is taken when Opus (wrongly) uses this function instead of its own.
Fixes#6041
Due to RNNoise being unmaintained and the library's code being in very
poor shape, this commit excludes the RNNoise feature from Mumble by
default and discourages its use.
The library contains Opus and CELT symbols (probably due to copy&paste
of code) that can end up being called from Opus instead of its own
versions of these functions. This can lead to completely unforeseen
behavior, including crashes.
An example of this is as of writing this, enabling RNNoise on macOS
leads to a crash of Mumble pretty much as soon as it starts up with an
"invalid instruction" error. The reason being that part of RNNoise's
implementation of one of Opus's symbols contains a code path that
produces an invalid instruction in optimized builds (and a segfault in
debug builds) and this code path is taken when Opus (wrongly) uses this
function instead of its own.
Fixes#6041
Having different include files that are needed (and which are inter-dependent) to create your own plugin, makes things harder than it needs to be.
Therefore, all plugin header files (those for the "new" (1.4) plugin framework anyway) have been combined into one header file. Thus, developers now only have to download a single file and include that instead of having to figure out what files to download and what to include where.
Taking the chance, the version number has been removed from the header file's name. This allows one to track changes made to the API via git (which is not quite as easy if you create a new file every time you make a change).
Having different include files that are needed (and which are
inter-dependent) to create your own plugin, makes things harder than it
needs to be.
Therefore, all plugin header files (those for the "new" (1.4) plugin
framework anyway) have been combined into one header file. Thus,
developers now only have to download a single file and include that
instead of having to figure out what files to download and what to
include where.
Taking the chance, the version number has been removed from the header
file's name. This allows one to track changes made to the API via git
(which is not quite as easy if you create a new file every time you make
a change).
Instead of having a fixed setting that affects all build modes, we now
set LTO only for release builds (but then for all targets). This has the
advantage that a dev doesn't have to switch LTO on and off when
switching between Release and Debug builds.
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 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
Opus has been the go-to codec for years now and there is absolutely no
reason why one would want to use any of the legacy codecs (Speex or
CELT) its stead.
Thus, this commit completely removes the support for these codecs from
the Mumble client.
Incidentally, having different codecs available somehow even caused some
audio artifacts, which should now be resolved as well.
Fixes#4538
Although installing MFC is mentioned in setup_visual_studio.md,
identifying where the header file is expected from is not obvious.
A C++ environment may already be installed without MFC, where the VS setup docs may not be followed/opened before-hand.
Previously Mumble was using a custom binary format for transmitting data
via UDP (mainly audio). This has worked for a long time but besides
being inconvenient for 3rdParty implementors (they had to manually
re-implement encoding and decoding support for this format) this format
was not very flexible and changes to the data format were very hard.
In order to improve on this situation, this commit introduces changes
that allow to use Protobuf for the UDP messages as well (it's already
used for TCP). With that it should be relatively easy to extend/change
the UDP packet formats in the future and 3rdParty implementors can now
simply use Protobuf to handle decoding/encoding packets for them (much
less work and much less prone to errors).
Since the new Protobuf format is incompatible with the old UDP format,
this commit also includes support for dealing with older clients or
servers that don't recognize the new protocol yet. That way the new
protocol format is only used if both the client and the server are
recent enough to have it implemented (assumed to be the case >=1.5.0).
Note also that the server will make sure that clients using the old and
the new format can seamlessly communicate with one another.
Therefore, on the surface it should not be noticeable to the user which
protocol is currently used.
Note also that the new protocol format only supports Opus as an audio
codec. If one of the legacy codecs is to be used, the legacy packet
format has to be used as well. However, all codecs except for Opus will
be removed from Mumble in the future anyway.
Fixes#4350
The gRPC implementation never left the experimental state and never
reached a properly stable state to the point where we would feel good
about enabling it by default. In addition to that, there has been no
further attempts at finding and fixing the encountered issues in the
implementation (except #3947 but that was discontinued).
As such we had an essentially unmaintained piece of code in our server
implementation that was known to be buggy and that nobody wanted to fix.
In addition to that the implementation itself could not be considered
very clean or elegant and therefore only represented a few smelly
corners in our code base.
For this reason, we decided to remove the gRPC support entirely from
Mumble (for now).
What we hope to gain by that is:
- Prevent people from building unstable server versions and then coming
to us complaining that it crashed/misbehaved
- Removing (essentially) dead code
- Reduce the RPC implementation complexity
That last piece is crucial: By removing gRPC support we reduce the
amount of supported RPC frameworks to only one (ignoring DBus for now).
Our future plans include a refactoring of how RPC is being handled and
implemented and only having to worry about maintaining compatibility
with one RPC system is much easier than having to worry about two (with
(slightly) different APIs).
Once the RPC implementation has been rewritten, more RPC backends may be
reintroduced and in that process we might investigate adding a proper
gRPC implementation to the code (that then hopefully is more stable than
the current one).
Fixes#4567Fixes#4197Fixes#3496Fixes#3429Fixes#3265
This commit introduces an option that toggles between using a bundled
version of nlohmann_json (default) and looking for a version installed
on the system instead.
Fixes#5584
Encourage OS package maintainers to run tests by packaging=ON implying
tests=ON.
Keep online-tests=OFF by default since it is common practise for
packages to be built in unprivileged environments, e.g. without network.
Encourage OS package maintainers to run tests by `packaging=ON` implying
`tests=ON`.
Keep `online-tests=OFF` by default since it is common practise for
packages to be built in unprivileged environments, e.g. without network.
The library is readily available in OpenBSD's version of X[0].
Follow suit with Linux in enabling.
Noticed by the warning upon startup:
```
-<W>2022-01-21 02:30:40.548 GlobalShortcutX: No XInput support, falling back to polled input. This wastes a lot of CPU resources, so please enable one of the other methods.
+<W>2022-01-21 02:34:00.159 GlobalShortcutX: Using XI2 2.4
```
0: https://xenocara.org/
The concept of RELEASE_ID was dropped with PR #5401 in commit 6caa808e6.
Thus, drop its leftovers from the documentation.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
OS packages (at least on Linux and BSDs) prefer prepackaged libraries to
bundled/statically linked versions where possible.
Introduce `rnnoise` (default `ON`) and make `bundled-rnnoise` default to
it's value; this retains current behaviour.
This way, `rnnoise=OFF` disables use of RNNoise completely and a simple
`bundled-rnnoise=OFF` requires the system's library.
Tested on OpenBSD 7.0-CURRENT.
Having a separate RELEASE_ID just unnecessarily complicates drafting
releases. Plus, now that we are using different build numbers for every
new build anyway, a separate release ID is really not necessary.
Tracy (wolfpld/tracy) is a profiler that is aimed at
having a very low impact on the runtime performance and is thus suitable
to be used in production systems to figure out what is going on and how
the code is performing.
For the time being, this commit instruments only the server code.
Furthermore, the instrumentation is performed in a rather minimalistic
way that should suffice to start profiling audio and control message
processing but is definitely far from being complete. Further
instrumentation will be added on-demand.
Tracy (https://github.com/wolfpld/tracy) is a profiler that is aimed at
having a very low impact on the runtime performance and is thus suitable
to be used in production systems to figure out what is going on and how
the code is performing.
For the time being, this commit instruments only the server code.
Furthermore, the instrumentation is performed in a rather minimalistic
way that should suffice to start profiling audio and control message
processing but is definitely far from being complete. Further
instrumentation will be added on-demand.
In theory LTO could give us a bit more performance than what we are
currently seeing. Client-side this will probably not be very noticeably
but on the server-side a few drops of extra performance can't hurt.
LTO will be enabled by default in all non-Debug builds. It remains
disabled for Debug builds as this is expected to be the kind of build
that a developer will use when they perform their work and there it is
useful to be able to go through multiple iterations of the program,
without waiting long times on the linker each time.
