Don't just stop scanning the link groups after we tried one direction,
also try the other direction.
Otherwise:
source -> loopback1_in|loopback1_out -> loopback2_in|loopback2_out -> record
will first scan from loopback2_out downstream and finds loopback2_in in the same
group but without downstream links. Then when upstream scan is done,
loopback2_out is already scanned and will be skipped and so loopback1
stays IDLE.
We fix this by keeping track of the direction that we scanned a node in
and only stop when we scanned it in the same direction twice.
Make sure we can only suspend when the node is (going to) IDLE. We don't
really want to allow applications to suspend a node that is running or
starting up.
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.
See #3378
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.
