Voice calls can require special audio routing to work, such as by
switching the profile or opening an audio stream. Add a module to
monitor for the starting and stopping of a voice call.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Pipewire server uses the global "settings" metadata for adjusting its
own log level.
Make it a convention that clients may watch "log.level" in this metadata
with their client id as subject, for setting their own log level
dynamically.
Watch the global "settings" metadata for "log.level" changes for our id.
On changes, set our log level accordingly.
Now that we have proper module load order, we can have this shared
dbus connection in a module instead of the library. The module has
to be loaded before any other modules that need it, obviously.
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.
- parse settings from .conf file.
- create "sm-settings" metadata and copy settings as key value pairs
to it.
- put in place "persistent" behavior, control it with a special
setting.
- when persistent behavior is enabled.
- create a state file and update settings to it.
- monitor changes in the metadata and update the settings to state
file.
There is no need to have this as an optional module, since libintl
is a hard dependency of both PipeWire and GLib. This way we can keep
things a bit simpler and faster (no string copies and plugin lookups)
Bump meson dependency to 0.59 to benefit of the libintl lookup that
is now built into meson's dependency() function.
This allows scripts to declare when they have finished their loading,
so we can now also know when wireplumber is done loading and ready to
handle clients
Related to !313
Make a module that creates a route-settings metadata and provides
some helper functions to parse the json fields.
Load the route-settings module in the policy.
Move the Notification settings to the metadata. Listen for metadata
updates and update our state table.
Fixes#51
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 module provides an API to get/set volume controls on nodes,
using the same logic as pipewire-pulse, which means it will use
the device Route props when a node is associated with a device
that has this capability
This commit adds a WirePlumber module which stores the current route for
a given device, and implements the necessary interfaces to restore those
on startup.
The routes are stored as an array of objects in JSON format.
Please note that actually restoring routes on startup is not done by this
module but will be implemented separately in a future commit.
