Piggy back on the Latency param change to emit a stream changed event
because we now might have a link between the stream and a device.
We should really watch for new links and emit change events for the
streams that it links to.
Fixes#3522
This makes the clock.force-quantum setting and node.force-quantum
suspend all drivers and resume them in the new quantum.
This is essential in order to change the quantum on an IRQ based
driver because it will otherwise refuse to change the graph quantum.
Don't just forward the tag and latency events to the follower but let
the audioconvert aggregate and emit the updated tag/latency event
that is then configured on the follower.
When using the DSP mode of the audioconvert, this results in an
accumulated latency/tag from all the DSP ports instead of just
the last DSP port param update.
Put properties with media. prefix in tags in pw-cat.
Always first clear the params before we start enumerating new ones.
Otherwise we only clear them when we see the first result and there
might not be a result.
`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
