Make sure we can only suspend when the node is (going to) IDLE. We don't
really want to suspend a node that is running or starting up.
Deactivate the node while we suspend so that graph recalc because of the
unprepared links will not try to prepare the links again.
This might fix a race when a node is suspended at the same time it is
started and cause silence. It also fixes the issue of total silence when
doing "pactl suspend <node> 1" on a running node.
Start scanning from a non-driving runnable node in one direction and set
all linked intermedia nodes runnable as well.
This ensure that play -> driving_sink -> effect -> sink also sets the
effect and sink nodes to running.
Fixes #3405
The provider might fail to connect to the PipeWire core when starting up, so
when stopping we need to check the core is valid before attempting to acquire a
mutex on its loop.
The libcanberra calls use libtool, which can not be called from multiple
threads at the same time. Use a global lock to serialize these calls in
the x11-bell module.
This is only a problem when multiple libcanberra calls are made in the
same process, such when you load the x11-bell module twice. There is no
guarantee that other libcanberra calls will not interfere but for now
we only use libcanberra here.
Fixes#2834
For sink nodes, keep a separate device_info around for the sink and
the monitor source part of the node. Only emit changes for the sink
and monitor source part when it changed.
See #3388
Make sure don't handle names ending in .monitor as a valid sink (because
it's a monitor on the sink).
Make sure we don't return a sink (monitor) as a source accidentally but
only when explicitly requested by name with the .monitor extension.
Makes
pactl set-sink-volume alsa_output.pci-0000_00_1b.0.analog-stereo.monitor -5%
pactl set-source-volume alsa_output.pci-0000_00_1b.0.analog-stereo -5%
fail as expected.
We don't actually use this counter anywhere.
Change the counter to a mask that will contain object specific changes
to the params. This should make it possible to track what kind of
changes where done to the object and make it easier to emit the right
events later.
The wireplumber unit test sets metadata on object 15, which happens to
be a module.
Allow metadata on other objects for now. It would be nice to disallow
this in the future, though.
Tag the sink/source as HARDWARE when it's not virtual, the presence
of a DEVICE_API property is not a good check.
Make a method to check if a node is a NETWORK sink/source to make it
use the same logic everywhere.
Add a thead-loop.start-signal option that will do a signal before
entering the thread loop. Doing the signal in all cases can confuse
apps that don't expect the signal.
Make module-rt use the thread-loop.start-signal.
Fixes#3374
Since the recent changes to the RT module in Pipewire 0.3.75, some
applications such as those using OpenAL-Soft crash on startup if
neither the session nor the system bus is available. For example:
bwrap --dev-bind / / \
--bind /dev/null /run/dbus/system_bus_socket \
--bind /dev/null $XDG_RUNTIME_DIR/bus \
openal-info
Will result in a crash with the following error message:
dbus[1626147]: arguments to dbus_message_new_method_call() were
incorrect, assertion "path != NULL" failed in file dbus-message.c
line 1373.
This is normally a bug in some application using the D-Bus library.
The RT module previously failed to load if no bus was available, but
after the recent changes, the init. logic runs in a thread, and failing
to obtain the bus no longer causes the module to fail to load.
Then, functions called later such as `pw_rtkit_make_realtime` assume
the bus is available and try to use it, causing the error above.
Put the logic for obtaining and checking the bus back to `module_init`,
so the module fails to load again if no bus is available.
When the permissions change on a node for a client, only check the
link permissions if the nodes of the link belong to the client.
Otherwise, we might destroy a link when the permissions are removed
from a node for an unrelated client.
First check if we can adjust priorities with rlimits, if we can't and we
need to use rtkit, spawn a thread-loop to handle the rtkit stuff.
First do a pw_loop_invoke() to do the rtkit setup, including getting
some properties and then setting the nice level and rlimits.
Use pw_loop_invoke to queue rtkit realtime requests, this ensures we
always perform the requests after the setup and when the properties
are fetched.
See #3357
Don't use a timer but use an event to trigger a flush of the collected
data. We are now using a per-driver buffer and we don't want to make
this too large so make sure we flush the data quickly.
