For remote nodes, set the signal time before we wake up the server. For
non-remote nodes, ser the signal time in node_ready. This ensures we
take the time to start the graph into account.
Add a _fast callback function that skips the version and method check.
We can use this in places where performance is critical when we do the
check out of the critical loops.
Make all system methods _fast calls. We expect them to exist and have
the right version. If we add new versions we can make them slow.
Let the server calculate signal time when it starts the graph. Otherwise
we overwrite old values and we can't do stats.
We might be able to piggyback the signal time in the prev_signal_time
field later.
Don't make an extra eventfd for activating the remote-node, we can
use the server side eventfd and send them to the remote side using
the transport.
The remote node already adds the eventfd to the data-loop so avoids
doing the same on the server.
This makes driver nodes trigger all remote nodes directly instead of
going through an intermediate eventfd. For resuming nodes, we already
used the node eventfd directly so this only a small optimization
for the initial cycle start.
For client-nodes that use trigger, set the signal and wakeup time when
they start the server node. Also set finish time before we resume the
peers on the server.
Client-nodes should really resume the peers directly without going
through the server but this is something to improve later.
Calculate the stats at the start of the new cycle. The results will be
about the previous cycle but this gives more accurate results because
we can also include awake and finish times of remote nodes.
Make sure not to change the status of the activation in the ready event
so that we don't overwrite the status of the last cycle yet.
This means we can always set the AWAKE and awake_time, the remote node
might update it when triggered but that's ok.
After processing we can update the FINISHED state for non-remote nodes,
the remote nodes will update it after they complete the process
function.
Pass the ready status to the client-node using the state array.
Don't just SPA_STATUS_HAVE_DATA on the server side but use the value
from the client.
This avoids some potential extra work when a driver sink pulls in data
with the NEED_DATA ready callback but then the server performs the
actions (tee) as if it were SPA_STATUS_HAVE_DATA.
this event extends the bound_id event and sends the global properties as
well.
This can be used to get the object.serial, for example.
It can also be used in the future to let the server generate unique
property values, like the node.name, and let the client know about the
new property value.
First set some of the port flags and data, especially the owner_data
before calling pw_impl_port_set_mix(), which will use the owner_data
to send the mix_info.
See #2847
We don't always need to send buffers to a remote port, when the port
is an output port, all the mix ports use the same buffers. This means
that when we add another link to a port, we don't get the mix_info
anymore and then we don't know the peer_id and we don't complete the
link and we don't call the connection_callback.
Instead, send the mix_info right before sending the Buffer Io area. We
always do this for all mix io and after we have sent the buffers so this
is a better place.
Fixes#2841
For now, put a limit on the amount of items we can send and receive
over the native protocol. A more complex way of allocating and freeing
can be implemented later when we really need to raise the limits.
Fixes#2070
