7e599badec
* macOS: Pass JackMachSemaphore send right via mach_msg IPC Previously, JackMachSemaphore would communicate the send right for the semaphore object from the server to a client via a named service registered via `bootstrap_register`. However, to do this, it would register the semaphore's port as the service port directly. In theory this ought to be fine, however in practice, macOS `launchd`, which provides the `bootstrap_register` interface, does not correctly detect when such a port becomes dead, and incorrectly believes that the service that it provides is forever alive, even past the end of the `jackd` process' (and therefore the semaphore's) existence. This seems to be *specific* to semaphore ports, as `launchd` is expecting a standard IPC port, owned by the task, not the kernel. This prevents `jackd` from later registering another service with the same name, as `launchd` rejects the registration as conflicting with an active service. To get around this, `jackd` previously added a counter to the end of the named service registrations, allowing old services to remain in the system until the end of the session. To prevent things getting out of hand, this was capped at 98 service registrations for a given semaphore name. This led to #784, in which running a client for the 99th time resulted in the semaphore creation failing and the client failing to connect. As `launchd` outlives multiple runs of `jackd`, this situation persisted across restarts of `jackd`, requiring a restart of the user's session (i.e. a reboot) to fix. An initial attempt at fixing this (see #785) tried passing the port rights directly via shared memory, however mach is too clever for us and foils that plan by having port names be looked up in a per-task table (sensible when you think about it). In this commit, we use mach IPC messages to transfer the send right for the semaphore from the server to the client. By registering a standard IPC port with the bootstrap server, the service registrations are correctly torn down when the ports are destroyed. It works something like this: * Server creates IPC port and registers it globally via `bootstrap_register` * Server listens on IPC port for messages * Client looks up IPC port via `bootstrap_look_up` * Client sends it a message * Server replies with a message containing a send right to the semaphore's port * Client is then free to use the semaphore port as before. This resolves #784. * Improve error handling * Add myself to Authors |
||
|---|---|---|
| .ci | ||
| .github | ||
| android | ||
| autooptions | ||
| common | ||
| compat | ||
| dbus | ||
| example-clients | ||
| linux | ||
| macosx | ||
| man | ||
| posix | ||
| solaris | ||
| systemd | ||
| tests | ||
| tools | ||
| waflib | ||
| windows | ||
| .gitignore | ||
| .travis.yml | ||
| .wafupdaterc | ||
| AUTHORS.rst | ||
| COPYING | ||
| ChangeLog.rst | ||
| README.rst | ||
| README_NETJACK2 | ||
| doxyfile.in | ||
| jack.pc.in | ||
| svnversion_regenerate.sh | ||
| waf | ||
| wscript | ||
README.rst
`JACK2 <https://jackaudio.org/>`_
################################
.. image:: https://travis-ci.org/jackaudio/jack2.svg?branch=master
:target: https://travis-ci.org/jackaudio/jack2
.. image:: https://repology.org/badge/tiny-repos/jack-audio-connection-kit.svg
:target: https://repology.org/metapackage/jack-audio-connection-kit/versions
JACK2 aka jackdmp is a C++ version of the JACK low-latency audio server for
multi-processor machines. It is a new implementation of the JACK server core
features that aims at removing some limitations of the JACK1 design. The
activation system has been changed for a data flow model and lock-free
programming techniques for graph access have been used to have a more dynamic
and robust system.
- uses a new client activation model, that allows simultaneous client
execution (on a SMP machine) when parallel clients exist in the graph (client
that have the same inputs). This activation model allows to better use
available CPU on a smp machine, but also works on mono-processor machine.
- uses a lock-free way to access (read/write) the client graph, thus
allowing connections/disconnection to be done without interrupting the audio
stream. The result is that connections/disconnections are glitch-free.
- can work in two different modes at the server level:
- *synchronous activation*: in a given cycle, the server waits for all
clients to be finished (similar to normal jackd)
- *asynchronous activation*: in a given cycle, the server does not wait for
all clients to be finished and use output buffer computed the previous
cycle.
The audible result of this mode is that if a client is not activated
during one cycle, other clients may still run and the resulting audio
stream will still be produced (even if its partial in some way). This
mode usually result in fewer (less audible) audio glitches in a loaded
system.
For further information, see the JACK `homepage <https://jackaudio.org/>`_ and `wiki <https://github.com/jackaudio/jackaudio.github.com/wiki>`_. There are also the #jack and #lad chat channels on `freenode IRC <https://freenode.net>`_.