pw_log_set resets the log level of the logger to the Pipewire's current
level. Here, it's instead expected that the level is retained, so call
pw_log_set_level first.
It used to be that pw_init set the log level based on PIPEWIRE_DEBUG
value, but this is now done only when using Pipewire's default logger.
If 'disable.dsp' is set to TRUE, the adapter will always be configured in
passthrough mode. Then, if 2 adapters want to be linked with different formats,
the si-standard-link session item will automatically reconfigure one of the
adapters in convert mode so that the format matches.
We always use the output session item mode and format when configuring adapters,
unless the input session item is a device node and the output session item is
not a device node.
This is needed so that the async callback passed to _set_ports_format is called
when changing the adapter's port format and the port has not been removed or
added. Eg: when configuring the adapter in S16 convert mode to S32 convert mode.
The idle callback may be called after the object manager has been
destroyed, or the object manager may be destroyed while emitting
one of the signals from the idle callback, so it needs to be ref'ed
while the callback is running. g_cclosure_new_object ensures that
in both cases the code behaves correctly.
This copies the logic of media-session's logind module and allows
the bluez monitor to be active in only one user session at a time.
This is especially useful to avoid interference between the gdm
session and the actual user session, which momentarily both have
wireplumber running when logging in/out.
Fixes#54
This change also keeps the plugin always activated, regardless of whether the
DBus connection is closed or not, which is useful when the dbus service is
restarted.
This destroys the ALSA monitor when the DBus connection is closed, and
re-creates again the monitor when the Dbus connection is connected, so that
device reservation is restarted.
This change also keeps the plugin always activated, regardless of whether the
DBus connection is closed or not, which is useful when the dbus service is
restarted.
If PipeWire is built without V4L support, then
`monitor = SpaDevice("api.v4l2.enum.udev", config.properties or {})`
will result in a nil monitor. This commit adds a basic sanity check
to avoid further using the nil variable.
Thanks-to: Pascal Flöschel (initial bug report)
Thanks-to: George Kiagiadakis <george.kiagiadakis@collabora.com>
Bug: https://bugs.gentoo.org/813043
If PipeWire is built without Bluetooth support, then
`monitor = SpaDevice("api.bluez5.enum.dbus", monitor_props)`
will result in a nil monitor. This commit adds a basic sanity check
to avoid further using the nil variable.
Thanks-to: Pascal Flöschel (initial bug report)
Thanks-to: George Kiagiadakis <george.kiagiadakis@collabora.com>
Bug: https://bugs.gentoo.org/813043
It's useful downstream to be able to control building
tests, as there's not much use building them if we're
not going to run them.
Signed-off-by: Sam James <sam@gentoo.org>
Removing a link before it finished activating can lead to race conditions. If
the link is not active, we should schedule a pending rescan to make sure the
old link is only removed when active. This should fix the proxy activation
failed warnings.
It's not used elsewhere, so there is no good reason yet to expose it.
Besides, I expect that GLib will likely add a method in the future
to return the XDG_STATE_HOME (which is relatively new in the xdg spec)
* Make the flags public and give them nicer names
* Pass down the flags from the caller, so the caller can now explicitly
ask for looking into specific directories
* Rename the methods
* Remove and inline the wp_get_xdg_config_dir() method, since it's only
used internally
* Refactor the lookup dirs ordering to get both WIREPLUMBER_*_DIR env
variables to replace all the other directories. Previously, we were looking
for scripts in WIREPLUMBER_DATA_DIR, but we were also looking in /etc at
the same time (with precedence, even), which could result in unexpected
behaviour. Now, if a WIREPLUMBER environment variable is specified,
we only look in there.
On Exherbo we allow to install different Lua ABIs in parallel and
users can choose per-package which Lua ABI to use, e.g.
media/wireplumber LUA_ABIS: -* 5.3
However, wireplumber's build system doesn't provide a way of explicitly
requesting a specific version, which makes the build non-deterministic,
since you get a different result if you install today with Lua 5.3
installed and reinstall tomorrow after installing Lua 5.4.
To fix this, I introduced a `system-lua-version` option that allows to
specify an explicit Lua version to check for and build against:
> $ meson .. -Dsystem-lua=true -Dsystem-lua-version=5.4
> The Meson build system
> Version: 0.58.0
> Source dir: /mnt/development/scm/freedesktop/wireplumber
> Build dir: /mnt/development/scm/freedesktop/wireplumber/build/reconfigure
> Build type: native build
> Project name: wireplumber
> Project version: 0.4.1
> [...]
> Run-time dependency lua-5.4 found: YES 5.4.3
> [...]
> Build targets in project: 56
>
> wireplumber 0.4.1
>
> Lua version : 5.4.3 (system)
> systemd conf data : YES
If the specified version isn't found, the build will fail loudly:
> $ meson .. -Dsystem-lua=true -Dsystem-lua-version=5.5
> [...]
> Found CMake: /usr/host/bin/cmake (3.20.5)
> Run-time dependency lua-5.5 found: NO (tried pkgconfig and cmake)
> Run-time dependency lua5.5 found: NO (tried pkgconfig and cmake)
>
> ../meson.build:50:6: ERROR: Problem encountered: Specified Lua version "5.5" not found
