Since the loopback bluetooth source node is meant to be always used by
applications, this change hides the actual bluez sco-source node by marking
them as internal. This avoids showing 2 input devices in pavucontrol per BT
device if HSP/HFP profile is enabled.
When running multi-instance setups or when clients like wpctl want to
access the WpSettings instance, it makes no sense to load the entire
module-settings, which will also create sm-settings metadata instances.
This hides the loopback stream node from applications, making desktop
environments to not show the 'recording from microphone' icon (Eg gnome-panel)
when the bluetooth device is not recording yet.
This patch improves the bluetooth profile autoswitch so that it works with any
application that wants to capture from a bluetooth device. To do so, a loopback
source filter is created per connected bluetooth device. If an application wants
to capture audio from such loopback source filter, the profile in the associated
bluetooth device is changed to HSP/HFP. If there isn't any application connected
to the loopback source filter, the profile switches back to A2DP.
The 'target.dont_move' property is only meant to be used with 'target.object'
metadata property, not smart filters metadata properties. This was probably
left accidentaly unused when designing a solution for #524 involving smart
filters.
Fixes#558
Change design of WpLogTopic so that it allows for changing their log
levels at runtime.
Add wp_log_topic_register/unregister functions to track lifetime of the
topics.
Auto-register statically defined log topics.
Make the topic registration threadsafe, in case it is done from
constructors that run in a different thread than main thread.
This patch adds to wireplumber code to manage the Snap audio
permissions.
SNAP containers have two main "audio" rules:
* audio-playback: the applications inside the container can
send audio samples into a sink
* audio-record: the applications inside the container can
get audio samples from a source
Also, old SNAP containers had the "pulseaudio" rule, which just
exposed the pulseaudio socket directly, without limits. This
is similar to the current Flatpak audio permissions.
In the pulseaudio days, an specific pulseaudio module was used
that checked the permissions given to the application and
allowed or forbide access to the pulseaudio operations.
With the change to pipewire, this functionality must be
implemented in pipewire-pulse and wireplumber to guarantee
the sandbox security.
The current code checks for the presence of the pipewire.snap.id
property in a client, in which case it will read the
pipewire.snap.audio.playback and pipewire.snap.audio.record
properties, and allow or deny access to that client to
the nodes with Audio/Sink or Audio/Source media.class
property.
See !567 and pipewire!1779
This property indicates whether the filter can be directly linked with clients
that have a defined target (Eg: pw-play --target <filter-name>) or not. This can
be useful when a client wants to be linked with a filter that is in the middle
of the chain in order to bypass the filters that are placed before the selected
one. If the property is not set, wireplumber will consider the filter not
targetable by default, meaning filters will never by bypassed by clients, and
clients will always be linked with the first filter in the chain.
Fixes#554
This patch fixes the policy to not link the client to the default filter if the
client's defined target is found, is not a filter, does not have any other
filters linked with it. In this case, the client is therefore linked to the
actual defined target. On the other hand, if the client's defined target is a
filter, the client is linked to the first filter in the chain that has the same
target as the defined filter's target.
This is a copy/paste from the code that now lives in apply-routes.lua,
but there is no point since the route here is a real route param and
not a route_info structure.
When a manual change is applied, the store-or-restore-routes is the only
hook that gets executed for this event. In order to be able to test if a
route was changed, we need to reset all of them to 'active = false',
record the previous value of 'active' and test their difference.
Testing only the 'active' variable (and discarding 'prev_active') sounds
tempting here, but if a route is changed back and forth (from A to B
and back to A), there is nothing to reset the 'active' variable of A
when it gets deactivated and it will appear as previously active on
the second switch.
Related to: #551
Add command for changing log level for Pipewire or Wireplumber daemons
at runtime.
It can be done with pw-metadata, but make it easier so that the user
doesn't need to look up Wireplumber client ids.
