Don't directly update the quantum and rate in the driver position
when recalculating the graph or else clients might see different values
during one cycle.
Instead update another variable and copy this into the position when
we start a new cycle.
When a client produces output on a port and there is a link between the
output port and an input port of the client, make sure that the new
data appears on the input port.
We do this by keeping track of what links are between our ports and when
we get the peer id of a port input, we can related this to our port
again. Some mixer inputs will then fetch content from our own ports and
so we can prepare the output for them. This can be converting midi to
control messages or moving the output buffer id to the io area so that
the input mixer can pick up the new buffer.
Fixes#1839
Always pause processing until the main loop has processed the buffer
change callback. This makes it less likely for clients in the same
process to use a new buffersize before the other client has received
the callback.
In carla, one client is receiving the buffer size callback and the other
clients are expexted to be paused until the callback for the client is
completed.
Given that 10-bit colour is now becoming supported on Wayland, PipeWire
should be able to represent all the possible colour formats in order
for screen capture to work.
This commit adds all possible orderings of 10-bit RGB channels and 2
extra bits used for nothing or alpha in little endian to enum
spa_video_format. Note that Wayland only uses little endian for its
10-bit colour formats, and these are not the same as the big endian
formats in reverse order.
Move some warnings when a wakeup was missed to info messages. The
warning can repeat a lot and is otherwise quite useless and already
reported elsewhere.
Don't do the default latency calculation, it might interfere with
the client latency values. Instead just use the client values and
fold multiples of quantum in the quantum latency field.
When we don't have any input buffers, recalculate the rate match
size field so that we can know the size of the expected buffer.
We already do this when starting but it might have been done with
a different quantum.
When we increase the quantum past the tlength, we need to be able to
ask for more bytes than the tlength or else we will never exit this
underrun state. Look at the last required bytes and use that if it's
larger then tlength.
0 is a valid min latency so we can't use it as an unset value. Use
some large value instead and when nothing was configured, assume it
is 0.
Fixes#1839
When adding a listener, don't add a listener for the resampler because
it does not contribute to the result, we only listen for results from
the resampler.
The id is useless when dealing with props params, we need to use the
name of the property as the key. Also the id can clash with other ids
of other plugins.
Previously, the standard i/o stream and daemon logs
were not properly null terminated, which could cause
issues in `print_lines()` inside `log_test_result()`.
See #1710
Some follower nodes don't support all audioadapter params (For example, param
SPA_PARAM_Props is not supported by 'support.null-sink'). This change adds a
check to avoid unsuported errors when requesting a param that is not supported
by the follower.
Add PropInfo for all the params that we can configure at construct
time and also add them as PROP_params.
This way you can configure the headroom at runtime with this:
pw-cli s <id> Props '{ params = [ "api.alsa.headroom" 1024 ] }'
Allow clients to bind to different versions of the server object.
When the server object is newer, it will adapt to the older version.
If the server object is older and the client tries to call a newer
method, it will receive an error. The right thing for the client is to
then ignore this and not call the method again. It should also probably
first check the server version before calling newer methods.
If we are underrun, don't update the read pointer and let the write
pointer catch up.
If we don't have enough data to fill a buffer, skip all the available
data and wait for the new request to arrive.
Fixes#1857
If one of the link ports is remote, enforce shared memory for the
buffer data. We must not use MemPtr because it will not be possible
to transfer this to the remote client.
If none of the sides selected any buffer type but we need shared
memory for the data, select MemFd as the fallback. This avoids using
DmaBuf, that the client did not explicitly select.
For MemPtr memory, we use the fd of the buffer metadata and chunk
info. Check that the memory is also in this block.
Check that all the memory of the buffer fits in the memory block.
See #1859