This is to iterate params that are common to all ports, such as
EnumFormat or the supported IO areas. Mostly interesting for mixer and
splitter nodes so that we don't have to create a new port just to query
things.
Make a new function to iterate the port params and update the flags etc.
Make sure we clear the cache first and reset the flags. This makes it
possible to call check_params later again.
PulseAudio's property list can store arbitrary data, but
pw_properties can only store null-terminated strings.
So for the time being, ignore those values that don't
have null-terminators or have zero bytes inside.
The length of the value for each value in a property list is serialized
twice. Both the reference implementation and pipewire-pulse send
the same length, so be stricter and only accept a property list
if both lengths are the same.
resample.disable was made to default to true, but copying it to stream
properties was forgotten so it didn't have any effect. Make sure to copy
it.
This will also prevent different input/output streams from negotiating
to different rates, which would result to broken audio since we are just
passing sample data through.
Add a -P (--properties) option to create the context with custom
properties. This can be used to control the modules that are loaded, for
example when they have conditions.
Change the flag from MAPPABLE to UNMAPPABLE to ease compatibility.
Older servers with newer client will not set the flag and so memory is
mappable for the client.
Newer server will set the flag but the client will ignore it and act
like before.
gst_pad_get_current_caps may return NULL and passing that into
gst_caps_is_equal may result in fatal critical log due to the
"g_return_val_if_fail (GST_IS_CAPS (caps1)" check. Fix by checking for
NULL to avoid this.
The target.id might be needed to find existing targets.
Update the properties after setting the initial state for the node, it
is a driver for itself and the properties can make it a driving node
when the driver property is set.
There is no reason to use the fd to schedule process_node, we can call
it directly when we detect an underrun need to complete the cycle with
whatever data made it to the driver.
This avoids starting the graph while the process_node is running and
avoids some stuttering.
See #3937
Implement pw_impl_node_set_io() and do all the things that need to be
done in it, such as taking the clock.id, checking for driver etc.
We can then remove some code that tries to reimplement this, most
notably in the remote-node (where it was missing updates to the
target_rate and target_quantum and maybe related to #3845.
Only activate the nodes when it was not-triggered, do this check with an
atomic compare-and-swap so that we only activate a node once.
We might be able to use this later to make sure that we resume the
untriggered peer nodes when we remove a node from the graph.
The min should always be 1. We have other ways of bumping the number of
buffers to 2, like the ASYNC allocation flag which we can set if we are
also doing some async scheduling. We could make this an option later.
Otherwise, we would also allocate 2 buffers by default between the mixer
and the node, which is unnecessary.
Add link.min-buffers option to set the minimum amount of buffers to
create for links. Set this by default to 2 because we really need two
now in case the sink xruns and does async mixing.
Make this an option because in low-memory cases and when xruns are not
expected, we can set this to 1.
To check if the driver was not completed, check the pending state
instead of the status. This is more correct and we can do this a little
smarter by swapping the current state with 0 atomically.
When we detect a non-zero pending state, wake up the driver node.
Because we atomically swapped 0, we are the only ones doing this and it
will make the node process whatever was in the input ports instead of
underrunning.
Running 2 apps outputting to a sink and pausing one will still play the
output of the other one, this way.
See #3509Fixes#3937
Add a SPA_PARAM_BUFFERS_metaType in the Buffers object. This contains a
bitmask of the mandatory metadata items that should be included on a
buffer when using this Buffers param.
Make the buffer allocation logic skip over the Buffers params that
require unavailable metadata.
This can be used to, for example, enforce specific metadata to describe
extra buffer memory (such as the meaning of generic file descriptors).
One such use is the explicit sync, where an extra buffer data is needed
for the sync fd along with metadata that contains the sync_point.
Parse the metas right after we fixate the params and collec them in the
metas array. We don't have to loop twice and then we can simply pass the
prepared metas to alloc_buffers.
In case there are multiple Buffers params, take the first valid one and
ignore invalid ones.
