Operating on the assumption that every SPA handle
can reference any other older SPA handle, the only
safe destruction order is from youngest to oldest.
To achieve this, store all handles across all plugins
sorted by age (youngest first), and use that as the
order of destruction in `pw_deinit()`.
This line of thinking does not account for what happens
when a handle that is referenced by others is unloaded,
but it does not make that case worse either.
See #2881
Only enable pulse.idle.timeout for selected applications
(speech-dispatcher) and let other applications be. We can also
lower the minreq and min-quantum of speech-dispatcher now.
Fixes#2880
Imagine this case with pw-loopback:
- the output stream is created and connected
- the input stream is created and connected
- the output stream is linked first and input+output move to the
sink as the driver. Start is sent to input+output but delayed
for the driver until all is complete.
- the input stream is linked to a source. The source becomes the
new driver and input+output+sink is moved to the source.
- all completes, the source is sent the Start command because it is
a driver. The sink also completes but is not sent a Start Command
because it is no longer a driver.
-> sink is scheduled but not started and gives errors
This patch clears the pending state of a driver when it is no longer
a driver. This makes the new driver set a new state (and cancel the
old state) and all followers will start correctly.
Connect the playback stream before the capture stream since the capture
stream can otherwise trigger playback_process() before the playback node
has been activated.
Modules echo-cancel, filter-chain and loopback may print errors if no
applicable target nodes exist when they start up. For our products this
is not considered error/warning worthy, since the issue will resolve
itself once the target nodes exist.
We don't need to pass the client to the module create and load
functions, they can work without a client.
The only place the client is used is to access the properties to make a
new connection to pipewire. This is also however not a good idea, we
should simply use the defaults used by the context or else a client
could set strange properties like remote.name etc for these internal
connections.
Also removing the dependency of the client will make it possible to load
modules from the startup script or other modules later.
Many Gstreamer elements support transforming buffers via the
`image-orientation` tag. Use it to implement support for the new
VideoTransform meta.
In order for Gstreamer pipelines to enable support for these tags
usually the rotate method has to be set to `auto` or `automatic`,
e.g. `videoflip method=automatic`, `glimagesink rotate-method=automatic`
or `waylandsink rotate-method=auto`.
Also try to recycle a buffer if the current buffer_id is invalid.
Ignore -EPIPE from the sender, just ask for more data. -EPIPE is when
the sende runs out of buffers so in that case we need to recycle one
as well.
Fixes#2874
Wait for all pending Start commands from the followers to complete
before adding and starting the driver node.
This ensure that all links are set up and the nodes have received and
replied to the Start command and things can start without hickups.
Don't wait for the node to be added to the graph before we activate
the links to it.
We don't do the reverse for shutdown and the activation counters won't
actually be updated until the node is added.
Waiting can cause race conditions in some specific cases (see in
screen sharing unit test) because the driver node can start
pushing buffers before the link has sent the Buffer io area to the
ports.
With this fix, the receiver (input stream) will first trigger
the input link activation, then the Start command and then it will be
added to the graph.
This does not entirely fix the race conditions when starting. Ideally,
the driver node should wait until all pending Start commands of the
nodes in the graph have completed.
First we remove the node from the graph, then we disable all links
to it and then we Pause the node. It's possible that the node is still
scheduled while we remove the links. In this case we should not schedule
the node but resume the peer nodes. Also don't log a warning in this
case as it is expected.
Also don't log a warning when a node emits a ready event while it was
removed from the graph. This is also expected because we first remove
the node from the graph and then send the Pause/Suspend command to make
it stop emiting the ready events. Just ignore the event when this
happens.
See also !1449
Avoid scheduling non-active nodes by removing the eventfd source from
the data loop when the node is deactivated. Read any old value from the
eventfd when starting the node again in case it has been written to
while the source was removed from the loop.
The ready callback can still be called when the node isn't active since
it is not called via the eventfd.
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
Let the node.passive property make passive links. PIPEWIRE_LINK_PASSIVE
overrides the node property.
Add some nice tweaks for qsynth so that it suspends and fades out
nicely by default.
When we start, read the Position IO so that we collect the right quantum
etc before calling the process callback. This updates the requested
frames value in the buffer correctly with the current quantum instead of
using 0.
This fixes an issue in pw-cat with midi data. The first buffer has a
requested size of 0 and so the first events won't fit in it and are
discarded.
Fixes#2843
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
When a client is not sending any data when it should be and causes an
underrun, mark it as idle and record the timestamp.
When a client is idle for pulse.idle.timeout seconds, set the stream
as inactive. When more data is received, set it back to active.
Add a pulse.idle.timeout option to set a global server default or
a per-stream value. Set the server default to 5 seconds. A value of 0
can be used to disable this feature.
With this change, badly behaving clients that are not sending any data
will be paused so that the sinks can suspend to save battery power.
Fixes#2839
Make a method to pause and resume a stream and keep track of the paused
state of the stream. Use this function instead of setting the stream
inactive/active so that we get nice logging for each state change.
When a server is started, try to publish the pending services.
When a server is stopped, republish the services.
This makes it possible to load and unload the tcp protocol after loading
the zeroconf publish module and it will do the right thing.
Loop over the servers and use its family and port to publish the
zeroconf services.
This avoids exposing the services when we don't have any TCP servers
running to accept connections.
It also avoids exposing the services twice with both IP4 and IP6
addresses.
It also exposes the services with a port that is actually usable, in
case it's not the same as the default port.
