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
Make sure we mark the port invalid when we can't allocate an id
for it. Also check that the id does not exceed the max amount of
areas we have allocated and release resources correctly.
It is possible that the mixer input can't be created because of hitting
the max limits of dsp mixer or client-node. Make sure we handle those
errors, destroy the link and clean up properly.
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.
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
Output ports share the same buffers on all mix outputs and the buffers
are stored in a special mix area with id SPA_ID_INVALID.
The special mix area does not have the peer_id of the link, we need to
get that from the non-shared mix area.
This fixes some invalid peer port-id values in the set_mix_info event.
