Revamp the profiles section, making use of the inherits feature
and add commonly used profiles for systemwide & embedded use cases,
as well as profiles for a split-instance configuration where the
policy hooks run in a separate instance from the alsa, bluetooth
and camera monitors (which run in 3 separate instances respectively)
Also add an example on how to configure the loaded profile using
a config file instead of the CLI switch.
Fixes: #608
This allows to inherit all the profile definitions of another profile
before the current profile's definitions are parsed, allowing for
more complex structures to be present in the default wireplumber.conf
without too much copy-paste
In some cases, requires/wants dependencies are not enough. As we saw in
!617, the m-standard-event-source module needs to be loaded after all
the hooks, otherwise there may be missed events that the hook was
supposed to "catch", but they were delivered before the hook was actually
loaded. In a similar fashion, we have in purpose put all the "monitor"
components at the every end of the array because if we load them earlier,
they will create devices and nodes before all the hooks are in place to
react.
While in standard configuration we can work this around, in extended
user configurations with custom components, it is impossible to do this
without overriding the entire components array.
To fix this properly, introduce before/after dependencies. They work in
a similar fashion as they work with event hooks. They do not implicitly
"pull" any components to be loaded, but they affect the ordering if the
mentioned components are indeed present.
Note that for backwards compatibility reasons and unlike systemd units,
the "requires"/"wants" targets imply an "after" dependency on them.
Fixes: #600
This allows changing the metadata name in the configuration file
and get all the Lua scripts looking at this new settings metadata
without requiring any other code changes. It can be useful in
multi-instance setups where we'd like the instances to be isolated
and load their own settings instead of relying on each other for that.
This reverts commit 8012fbd5cf.
There seems to be some underlying bug that sometimes causes a crash
when the Bluetooth monitor uses a loopback for autoswitching between
profiles. Reverting temporarily until the cause is fully determined.
See #682
With this change, it is possible to have a top-level object that does
not start at exactly the beginning of the file, allowing comments and
whitespace to exist.
Also add an empty conf file in the tests to verify that
it does not crash.
A bit of refactoring was needed in order to avoid breaking as-section
loading, which expects the entire file to be an object or array and doesn't
parse it.
Fixes: #633
In some cases the monitors emit the object_info callback with the same id
and non-NULL info multiple times. For example, when an ACP profile changes from
output:analog-stereo+input:analog-stereo to just output:analog-stereo, it emits
object_info() with NULL info for the input node and object_info() with updated
properties and the same id as before for the output node.
This causes the spa-device here to emit create-object multiple times for the
same object and this breaks the name deduplication logic. To solve this, make
sure we emit object-removed before calling create-object a second time.
Fixes#500
At the moment, the same transition can be completed multiple times
(assuming sufficiently high reference count):
return_error()
finish()
return_error()
The consequence of that is that the transition closure will be
invoked multiple times. This is unexpected.
Add some guards against completing a transition or calling finish()
multiple times.
Fixes#628
Make decision on whether to show code location in journal messages based
on whether the WpLogTopic would enable DEBUG level messages.
Add wp_logt_checked API to take WpLogTopic as input to make this
possible, and deprecate wp_log_checked.
Logging messages are usually developed based on the stderr logging,
which shows code location and log topics as context, and especially
higher log level messages can be cryptic or useless without that
context.
This context is not shown in journalctl by default, and so usually is
missing from logs submitted by users. In principle it is available in
journalctl but requires extra work to show it.
Fix by prepending the log topic to the messages, like Pipewire logging
does. Also show code locations if log level is high enough.
Currently nothing removes the WpLoopSource from the main context, and we
moreover are creating and attaching unused WpLoopSources when sharing
same pw_context between multiple WpCore.
Fix this by keeping track of the WpLoopSource in the pw_context user
data, only creating them when needed, and finalizing it after the
context is destroyed.
It is intended that the Pipewire loops are "entered" the whole time they
are running, i.e. are going to process further events. Currently we
enter/leave for single iterations, which is not right.
Fix by entering the loop on initial GSource idle callback, and leaving
at finalize.
That the loop has to be left from the same thread it was entered from is
a bit hard to do with GSources, as the finalize callback appears not
guaranteed to be called from any particular thread. I didn't find a
fully general way to do this, so this puts additional constraints on how
WpLoopSource (and WpCore) are to be cleaned up.
If we use the project version as library version,
it is not possible to append something to the
project version to indicate a modified wireplumber version.
A "plain" JSON object may be passed to WpConf constructors. Previously, this
would cause an error as open_and_load_sections expects the first parsed token
to be a string. Use WpProperties to denote that the file being parsed is an
object/container, and specify a section name for it.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Use WpProperties to indicate that searching for and loading
conf.d fragments can/should be skipped.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
WpProperties may be used to control the behaviour of a WpConf
object. This allows those properties to be referenced at any time
during the lifetime of a WpConf.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
The signature of the function is quite misleading. If an absolute
path is passed to it, it will ignore the directory constraint flags
and search outside of the specified directories anyway. Make a note
of this in its caller.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
The absence of parenthesis confuses the gobject-introspection parser
for some reason, making it emit WP_BASE_DIRS_FLAG_SUBDIR_WIREPLUMBER
multiple times in the .gir file
Define WP_USE_LOCAL_LOG_TOPIC_IN_G_LOG in project scope, so that we always
use this feature in our codebase without causing problems for other projects.
Fixes#571
Add a new private header file, wpbuildbasedirs.h, that contains the
build-time base directories passed directly from meson, without
the "wireplumber" suffix.
Use this to set the WP_BASE_DIRS_BUILD_* and adjust the code to honor
the SUBDIR_WIREPLUMBER flag.
This removes the previous hardcoding of this suffix and allows the
functions to be useful to other projects that use libwireplumber
and want to use this code to locate their data & config.
We do not use these APIs, so there's no point in keeping them.
Realistically, every component that needs a section just does its
own parsing on it, so the _get_value() functions are not needed.
The fallback in _get_section() is also not needed, as we always
pass NULL and then test for it. In Lua, however, it seems we are
using the fallback to return an empty object, so that getting
a section does not expand to multiple lines of code. For that reason,
I have kept the syntax there and implemented it in the bindings layer.
Changes:
- Configuration files are no longer located by libpipewire,
which allows us to control the paths that are being looked up.
This is a requirement for installations where pipewire and
wireplumber are built using different prefixes, in which case
the configuration files of wireplumber end up being installed in
a place that libpipewire doesn't look into...
- The location of conf files is now again $prefix/share/wireplumber,
/etc/wireplumber and $XDG_CONFIG_HOME/wireplumber, instead of using
the pipewire directories. Also, since the previous commits, we now
also support $XDG_CONFIG_DIRS/wireplumber (typically /etc/xdg/wireplumber)
and $XDG_DATA_DIRS/wireplumber for system-wide configuration.
- Since libpipewire doesn't expose the parser, we now also do the
parsing of sections ourselves. This has the advantage that we can
optimize it a bit for our use case.
- The WpConf API has changed to not be a singleton and it is a
property of WpCore instead. The configuration is now expected
to be opened before the core is created, which allows the caller
to identify configuration errors in advance. By not being a singleton,
we can also reuse the WpConf API to open other SPA-JSON files.
- WpConf also now has a lazy loading mechanism. The configuration
files are mmap'ed and the various sections are located in advance,
but not parsed until they are actually requested. Also, the sections
are not copied in memory, unlike what happens in libpipewire. They
are only copied when merging is needed.
- WpCore now disables loading of a configuration file in pw_context,
if a WpConf is provided. This is to have complete control here.
The 'context.spa-libs' and 'context.modules' sections are still
loaded, but we load them in WpConf and pass them down to pw_context
for parsing. If a WpConf is not provided, pw_context is left to load
the default configuration file (client.conf normally).
