mirror of
https://github.com/mumble-voip/mumble.git
synced 2025-10-26 11:19:16 +00:00
Mumble is an open-source, low-latency, high quality voice chat software.
audioclientcmakecross-platformgaminghacktoberfestlinuxmacosopen-sourcequality-voice-chatservervoicechatvoipwindows
dee463ef52
Using a QueuedConnection for the slot had the unpleasant side effect that the QSocketNotifier could have its activated() slot invoked even though no data was waiting to be read. In our case, this could cause a deadlock inside Avahi's libdns_sd compatibility library. I've settled on using Qt::AutoConnection to be consitent with the rest of the code base. The Bonjour code should always be invoked from the main thread, so in this case Qt::AutoConnection will always mean Qt::DirectConnection. Why does this happen? Qt seems to process events before invoking queued slot invocations. If the Qt event loop finds that the file descriptor that our QSocketNotifier is providing notification for is ready for reading, it queues up an invocation of the activated() slot for the next event loop iteration (because we use a QueuedConnection). As mentioned above, because Qt seems to poll() FDs before invoking queued-up slots, the end result is that an invocation of the activated() slot for a given QSocketNotifier's file descriptor can be queued up in the very same event loop iteration that a read() is performed for the exact same file descriptor. After performing the read(), the queued-up activated() slot invocation is no longer valid, and can wreak havoc, which in our case causes a deadlock in the Avahi libdns_sd code. The flow below describes the event loop iterations in more detail: 1st event loop iteration ------------------------ * poll() is invoked; the QSocketNotifier's FD is ready for reading. * An invocation of the activated() slot is queued up, to be executed next time we enter the event loop (due to Qt::QueuedConnection). 2nd event loop iteration ------------------------ * poll() is invoked; the QSocketNotifier's FD is _still_ ready for reading. * An invocation of the activated() slot is again queued up, to be executed in the 3rd iteration. * The queued-up slot invocation from the 1st iteration is invoked. (read() is called.) 3rd event loop iteration ------------------------ * poll is invoked(); the QSocketNotifier's FD has nothing to read anymore. Everything was read in the activated() slot that was invoked in the 2nd iteration. * The queued-up slot invocation from the 2nd iteration is invoked. This time, the read() syscall will block, because there is nothing to read. |
||
|---|---|---|
| 3rdPartyLicenses | ||
| celt-0.7.0-build | ||
| celt-0.7.0-src@6c79a9325c | ||
| celt-0.11.0-build | ||
| celt-0.11.0-src@e3d39fec7c | ||
| doc | ||
| g15helper | ||
| icons | ||
| installer | ||
| macx | ||
| man | ||
| opus-build | ||
| opus-src@d060dd7cbd | ||
| overlay | ||
| overlay_gl | ||
| plugins | ||
| samples | ||
| sbcelt-helper-build | ||
| sbcelt-lib-build | ||
| sbcelt-src@a2ce9cf9b8 | ||
| scripts | ||
| speex@a6d05eb5ff | ||
| speexbuild | ||
| src | ||
| .gitignore | ||
| .gitmodules | ||
| CHANGES | ||
| compiler.pri | ||
| Doxyfile | ||
| INSTALL | ||
| LICENSE | ||
| main.pro | ||
| README | ||
| README.Linux | ||
| README.static.linux | ||
| README.static.osx | ||
| symbols.pri | ||
| winpaths_default.pri | ||
M U M B L E
A voicechat utility for gamers
http://mumble.info/
#mumble on freenode
Mumble is a voicechat program for gamers written on top of Qt and Speex.
There are two modules in Mumble; the client (mumble) and the server
(murmur). The client works on Win32/64, Linux and Mac OS X, while the
server should work on anything Qt can be installed on.
Note that when we say Win32, we mean Windows XP or newer.
Running Mumble
==============
On Windows, after installation, you should have a new Mumble folder in your
Start Menu, from which you can start Mumble.
On Mac OS X, to install Mumble, drag the application from the downloaded
disk image into your /Applications folder.
Once Mumble is launched, you need a server to connect to. Either create your
own or join a friend's.
Running Murmur on Unix-like systems
===================================
Murmur should be run from the command line, so start a shell (command prompt)
and go to wherever you installed Mumble. Run murmur as
murmurd [-supw <password>] [-ini <inifile>] [-fg] [v]
-supw Set new password for the user SuperUser, which is hardcoded to
bypass ACLs. Keep this password safe. Until you set a password,
the SuperUser is disabled. If you use this option, murmur will
set the password in the database and then exit.
-ini Use a inifile other than murmur.ini, use this to run several isntances
of murmur from the same directory. Make sure each instance is using
a separate database.
-fg Run in the foreground, logging to standard output.
-v More verbose logging.
Running Murmur on Mac OS X
==========================
On Mac OS X, Murmur is available inside your Mumble application bundle. If you
copied the Mumble program into your Applications directory, you should be able
to run it by executing:
/Applications/Mumble.app/Contents/MacOS/murmurd -v -fg
in a Terminal. For more information, please see the 'Running Murmur on Unix-
like sytems' above.
To easily override the default Murmur configuration, a murmur.ini file can be placed in
your user's 'Library/Preferences/Mumble/' directory.
Example configuration files and other scripts can be found inside the Murmur
directory of the Mumble installation disk image.
Running Murmur on Win32
=======================
Doubleclick the Murmur icon to start murmur. There will be a small icon on your
taskbar from which you can view the log.
To set the superuser password, run murmur with the parameters '-supw <password>'.
Bandwidth usage
===============
Mumble will use 10-40 kbit/s outgoing, and the same incoming for each user.
So if there are 10 other users on the server with you, your incoming
bandwidth requirement will be 100-400 kbit/s if they all talk at the same time.