e7e5c66853
* rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire |
||
|---|---|---|
| lib | ||
| modules | ||
| src | ||
| tests | ||
| .editorconfig | ||
| .gitlab-ci.yml | ||
| LICENSE | ||
| Makefile | ||
| meson.build | ||
| meson_options.txt | ||
| README.md | ||
WirePlumber
WirePlumber is a session / policy manager implementation for PipeWire.
Compiling and Running
Dependencies
In order to compile WirePlumber you will need:
- GLib >= 2.58
- PipeWire 0.3 (master)
At the moment, due to heavy development of both PipeWire and WirePlumber,
it is not always the case that the latest master of WirePlumber works with the
latest master of PipeWire. The safest PipeWire branch to use with WirePlumber
master is the agl-next branch from
my personal clone
Compilation
WirePlumber uses the meson build system. For compatibility and ease of use, though, a Makefile is also provided. The Makefile works only after the initial configuration of the project with meson.
Here is the very basic sequence of compiling for the first time:
$ meson build
$ make
Running automated tests
WirePlumber has a few automated tests that you can easily run with:
$ make test
Running
- First of all, you will need to run PipeWire. PipeWire itself comes with
an example session manager that you will need to disable in order to run
WirePlumber. This can be achieved by editing
src/daemon/pipewire.conf.inon the PipeWire git tree to disable the execution of the session manager:
diff --git a/src/daemon/pipewire.conf.in b/src/daemon/pipewire.conf.in
index bf64c574..e733e76c 100644
--- a/src/daemon/pipewire.conf.in
+++ b/src/daemon/pipewire.conf.in
@@ -24,4 +24,4 @@ load-module libpipewire-module-access
load-module libpipewire-module-adapter
load-module libpipewire-module-link-factory
load-module libpipewire-module-session-manager
-exec build/src/examples/media-session
+#exec build/src/examples/media-session
-
Second, you will need to run pipewire: in the pipewire source tree, do
make run -
Without stopping pipewire, in the wireplumber source tree, do
make run
Testing with an audio client
The easiest way to test that things are working is to start a gstreamer pipeline that outputs a test sound to pipewire.
In the pipewire source tree, do:
$ make shell
$ gst-launch-1.0 audiotestsrc ! pwaudiosink
Note that pwaudiosink is currently only available in the agl-next branch.
Debugging
The Makefile included with WirePlumber also supports the gdb and valgrind
targets. So, instead of make run you can do make gdb or make valgrind
to do some debugging.
Getting debug messages on the command line is a matter of setting the
G_MESSAGES_DEBUG environment variable as documented in the GLib documentation.
Usually you can just do:
G_MESSAGES_DEBUG=all make run
Note that this only gives out WirePlumber's debug messages. If you want to also see libpipewire's debug messages, then you can also set:
PIPEWIRE_DEBUG=4 G_MESSAGES_DEBUG=all make run
... where PIPEWIRE_DEBUG can be set to a value between 1 and 5, with 5 being the
most verbose and 1 the least verbose.