mumble-voip / libmumble Goto Github PK

When I try to build this lib on my machine, I get the following cmake warning:

CMake Warning at src/CMakeLists.txt:11 (find_package):
  By not providing "FindOpus.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Opus", but
  CMake did not find one.

  Could not find a package configuration file provided by "Opus" with any of
  the following names:

    OpusConfig.cmake
    opus-config.cmake

  Add the installation prefix of "Opus" to CMAKE_PREFIX_PATH or set
  "Opus_DIR" to a directory containing one of the above files.  If "Opus"
  provides a separate development package or SDK, be sure it has been
  installed.

I'm having trouble building the library on a Raspberry Pi Zero 2W (Linux_ 5.15.76-v8+ #1597 SMP PREEMPT Fri Nov 4 12:16:41 GMT 2022 aarch64 GNU/Linux).

The first problem I had was related to quickpool. I had a a CMake Error when configuring with cmake version 3.18.4 at quickpool/CMakeLists.txt:21 (add_library):
add_library INTEFACE library requires no source arguments.
I was able to successfully configure the project using the prebuilt newest version of cmake (3.25.1-linux-aarch64). Unfortunately running make in the root directory the build process now fails with the error:
src/proto/CMakeFiles/Proto.dir/build.make:73: *** target pattern contains no '%'. Stop.

I cannot reproduce the error on my desktop environment running Arch Linux and the same cmake version 3.25.1. Everything works as expected there.

The according lines in the autogenerated makefile read:

 72 src/proto/MumbleTCP.pb.h: src/proto/MumbleTCP.proto
 73 src/proto/MumbleTCP.pb.h: src/proto/protobuf::protoc
 74         @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold --progress-dir=/home/pi/libmumble/CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Running cpp protocol buffer compiler on MumbleTCP.proto"
 75         cd /home/pi/libmumble/src/proto && protobuf::protoc --cpp_out /home/pi/libmumble/src/proto -I /home/pi/libmumble/src/proto /home/pi/libmumble/src/proto/MumbleTCP.proto

It appears that there is a problem with either the name src/proto/MumbleTCP.pb.h or src/proto/protobuf::protoc. One possible problem could be that regular expressions in make get evaluated by the shell and maybe the shell is the problem.

Hello everyone,

I am trying to build a simple VOIP app using your SDK. I managed to setup several clients and a server and connect those clients to the server, capture, encode and send the audio data as well as decode and render the received audio data. It works great when there are just two people in the call, but the issue arises when another one joins. For example, when two people start talking at the same time and the third one is listening - the mixed signal is audible meaning third person can understand the other two but there is some clicking/popping in the mixed signal. This is not an issue with the SDK but the mixed signal that is being played. I am just wondering if you encountered something like this during the development of the official Mumble/Murmur? I implemented very simple jitter buffer that just delays playing the audio for 200ms just to rule out this as a potential problem.

Best regards,
Dejan

I'm working on a project involving VOIP Communication on Raspberry Pi Zeros within a local Network. I would like to write the code in C++. Reading this project's description in the "readme.md" branch sounds very promising and it appears like this project could be a perfect fit.

I was able to build the examples but I'm not sure if it is worth going any deeper for now since I'm not sure how advanced this project is. Would the state of this project be sufficient for a minimal VOIP-Application involving a few participants within a single channel? I don't mind the lack of documentation since the code appears to be very readable and clean.

Thanks for the promising project.

I've test library with mumble-server based on mumblevoip/mumble-server:v1.4.287

After I have connected (and sent Ping messages to server) I got an SSL_ERROR_SYSCALL in TLS.cpp and then got Shutdown and closed TCP.
You need to be connected a lot of time (from 10 minutes to 10 hours) to reproduce
https://github.com/mumble-voip/libmumble/blob/master/src/TLS.cpp#L184-L190

top of stacktrace:

#0  mumble::SocketTLS::interpretLibCode (this=0x55555566b760, code=0, processed=false, remaining=true) at /PATH/libmumble/src/TLS.cpp:194
#1  0x00007ffff7f72682 in mumble::SocketTLS::read (this=0x55555566b760, buf=...) at /PATH/libmumble/src/TLS.cpp:161
#2  0x00007ffff7f2b21a in mumble::Connection::P::read(gsl::span<std::byte, 18446744073709551615ul>, bool, std::function<bool ()>) (this=0x55555566b760, buf=..., wait=false, halt=...) at /PATH/libmumble/src/Connection.cpp:156
#3  0x00007ffff7f2ac81 in mumble::Connection::process(bool, std::function<bool ()>) (this=0x5555556193c0, wait=false, halt=...) at /PATH/libmumble/src/Connection.cpp:101
#4  0x00007ffff7f591ef in operator() (__closure=0x7ffff0028dc0, event=...) at /PATH/libmumble/src/Peer.cpp:299
#5  0x00007ffff7f59ac1 in operator() (__closure=0x7ffff0028dc0, i=0) at /PATH/libmumble/3rdparty/quickpool/quickpool.hpp:928
#6  0x00007ffff7f5a35b in quickpool::loop::Worker<quickpool::ThreadPool::parallel_for_each<gsl::span<mumble::Monitor::Event>, 

I check ERR_get_error() is 0 and errno is 11 inside SSL_ERROR_SYSCALL case

auto sslError = ERR_get_error();
auto err = errno;

After my little patch a have no random disconnect anymore

diff --git a/src/TLS.cpp b/src/TLS.cpp
index 8ea8176..136f4db 100644
--- a/src/TLS.cpp
+++ b/src/TLS.cpp
@@ -182,6 +182,9 @@ uint32_t SocketTLS::pending() const {
 		case SSL_ERROR_WANT_WRITE:
 			return WaitOut;
 		case SSL_ERROR_SYSCALL:
+			if (ERR_get_error() == 0 && errno == 11) {
+				return Retry;
+			}
 			m_closed = true;
 
 			if (!processed) {

But I'm not sure this is enough and this is idiomatic code for handling ssl problems

Related links from so:
https://stackoverflow.com/questions/13686398/ssl-read-failing-with-ssl-error-syscall-error
https://stackoverflow.com/questions/13554691/errno-11-resource-temporarily-unavailable

Instead of using a hard-coded max size for receiving UDP packets limits what kind of extensions can be made in the future as older clients would simply drop incoming packets that they consider too large, even if technically the Mumble protocol now allows larger packets.

Thus, it would be better to simply take packets in the size in which they come, with some sane upper bound to prevent malicious packets from overflowing a peer.

Hi,
I‘m very interested about this lib; for integrating the fgcom-mumble plugin directly into flightgear flight simulator.

Is it planned to make an interface to load a compiled plugin into the lib, so it calls the hooks?