The intention is to make checks for enabled log topics faster.
Every topic has its own structure that is statically defined in the file
where the logs are printed from. The structure is initialized transparently
when it is first used and it contains all the log level flags for the levels
that this topic should print messages. It is then checked on the wp_log()
macro before printing the message.
Topics from SPA/PipeWire are also handled natively, so messages are printed
directly without checking if the topic is enabled, since the PipeWire and SPA
macros do the checking themselves.
Messages coming from GLib are checked inside the handler.
An internal WpLogFields object is used to manage the state of each log
message, populating all the fields appropriately from the place they
are coming from (wp_log, spa_log, glib log), formatting the message and
then printing it. For printing to the journald, we still use the glib
message handler, converting all the needed fields to GLogField on demand.
That message handler does not do any checks for the topic or the level, so
we can just call it to send the message.
Previously we were mapping SPA ERROR to GLib WARNING and
SPA WARN to GLib MESSAGE, which has been causing some confusion.
After some careful consideration, it makes sense to change that and
leave the GLib MESSAGE level as something to be avoided. With that
change, WIREPLUMBER_DEBUG=M will still enable the MESSAGE level,
but WIREPLUMBER_DEBUG=2 will only enable the WARN level and it will
take WIREPLUMBER_DEBUG=3 to enable both the INFO and MESSAGE levels.
Since the wireplumber configuration has been moved to /usr/share/pipewire, it
does not makes sense to have a different path for the WIREPLUMBER_CONFIG_DIR
environment variable. Therefore, the WIREPLUMBER_CONFIG_DIR environment variable
has been changed to just be an alias of PIPEWIRE_CONFIG_DIR. Finally, Lua
scripts are now installed under /usr/share/wireplumber/scripts instead of
/usr/share/pipewire/scripts as they are a wireplumber feature only.
This change completely refactors the way components are loaded in wireplumber:
- The module_init() function must return a GObject now. This object is either
a WpPlugin or a WpSiFactory in the current modules.
- When the component loader initializes a module, it automatically registers
the WpPlugin or WpSiFactory with their respective methods. There is no need
to register the WpPlugin or WpSiFactory in the module now.
- The wp_core_load_component() API has been refactored to be asynchronows. This
allows the component loader to automatically activate WpPlugin objects, and
therefore allows the application to directly get the WpPlugin without having
to find it. This simplifies a lot of things.
- The 'ifexists' and 'nofail' component flags now work even if the respective
WpPlugin could not be activated.
- The code that loads components in main.c has also been simplified a lot,
and the option to load dangling components has also been removed.
This patch also moves nested configuration objects that are not considered
settings from the wireplumber.settings section to its own configuration
section (eg the rules array, the spa plugin properties, etc...). This allows
those objects to be merged with other same sections defined in other files.
* Remove entirely the hook priority numbers and use before/after dependencies
* Split the WpEvent code out of WpEventDispatcher
* Add methods on WpEvent to interface with it from the WpEventDispatcher.
As a bonus, we can now also implement tooling to inspect which hooks would
in theory run for an event and write tests around that
* Removed some internal debugging facilities and log calls, will redo it later.
* Using spa_list now for the list of hooks, to reduce the number of allocations
happening in the "hook collection" algorithm
* Switched some internal data to use g_new0 instead of g_slice_new0
* Added g_free to free WpEvent structures... surprisingly, we were leaking them
before
Hooks need to have a priority relative to the event they are executed on,
so it does not make much sense to have all kinds of different priorities
based also on the event type and/or the module where they are defined.
Also, it wouldn't be acceptable to have such an enumeration on the public API.
after-events-with-event hooks are rendered based on the priority, this means
when a rescan event happens, all the findDefinedTarget hooks(of different
session items) are run first and then all the findDefinedTarget hooks, so on.
This kind of scheduling of hooks was removing the established link between zoom
voice engine and digial mic. Also It is slightly difficult to follow the flow in
the logs.
Instead of arranging the hooks flately based on priority, better scheme to
prioritize them in two layers. First all the hooks for an event or session items
are grouped and with in that group, priority of the hook is honored.
src/scripts/policy-hooks.lua # modified: src/scripts/policy-node.lua #
- Sharpen the hooks, so that they are called only when needed.
- Make settings live, apply them when they are changed.
- Remove the state saver after events hook, call it directly.
- Remove the settings bookkeeping as the gobject properties.
- Remove the scheduling of default-nodes-changed signal via core.
- WirePlumber Lua now facilitates Lua libraries/modules, utilize this and create
modules. Add some tests around this functionality.
- Create policy-hooks.lua containing all the hooks to find-target events
- Create policy-utils.lua module and push all the policy utility functions to it.
- Create common-utils.lua module and push the common utility functions to it.
- Remove all the above functionality from policy-node.lua and clean it up.
after-events hooks are instantiated with rescan event, not with the event which
actually triggered it. after-events-with-event fills this gap.
policy-node clean needed this kind of hooks.
They is really no needed with the new _get() API and the WpSpaJson API. In C,
users can use 'wp_spa_json_parse_{boolean|int|float|string}()' APIs to parse the
WpSpaJson. In Lua, users can just do 'Settings.get(setting, m):parse()'.
We need to use WpSpaJson to parse the values in WpSettings. This is because the
wireplumber configuration is written in JSON, so WpSettings should only hold
JSON values. To fix this, 2 API changes have been done:
- wp_settings_get_int() only accepts gint values, instead of gint64 values. This
is because the WpSpaJson API only parses int values, like spa_json_parse_int().
- wp_settings_get_string() now returns a newly allocated string, this is because
the string needs to be decoded in case it has quotes.
