`wpctl status` shows the description of device nodes. Therefore, the
videotestsrc and audiotestsrc are listed as "(null)" if the example
configuration of the sources is used.
Set the description in the example for how to configure the audiotestsrc
and the videotestsrc.
Let the source write into a ringbuffer when there is data available.
We then read from the ringbuffer when scheduled and use a dll to keep
the delay constant. We can later make this a driver and use the rate
correction to tweak the timeouts instead of resampling.
See #3478
Round down the size and avail to the frame size to make sure we always
send aligned frames.
When we don't have the required size, set the buffer to 0 but still send
whatever we have in the ringbuffer or else it stays there until some
unknown time when it gets flushed out again with new data.
The tag param has a list of arbitrary key/value pairs. Like the Latency
param, it travels up and downstream. Mixers will append the info
dictionaries or do some more fancy merging.
The purpose is to transport arbirary metadata, out-of-band, through the
graph and it's used for stream metadata and other stream properties.
When we don't have a pending target duration/rate update, take the
currently configured clock target duration/rate as the target rate.
This needs to be done when the driver refuses to update the duration and
rate for some reason and places its own values in clock target duration/rate.
Otherwise we would think the driver is using some other duration than
what it is really using.
Try:
- set alsa to irq based playback that refuses to change the quantum
- paplay with some file that sets the quantum to 1024
- pw-metadata -n settings 0 clock.force-quantum 256
- the target duration will be set to 256 but alsa doesn't change it
- stop playback
- start playback again, the quantum is still 1024 and not 256
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
