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.
The monitor mode does not create a echo-cancel-playback node, and makes the
echo-cancel-sink node to be a monitor node with media class Stream/Input/Audio
(instead of Audio/Sink).
Some applications get confused when their output stream node is not linked
directly to the actual device node. Having echo-cancel-sink as a monitor node
avoids this problem, allowing those applications to work properly even if echo
cancel is enabled.
This mode is disabled by default. You can enable it by passing the specific
option (monitor.mode = true) in the args when loading the module in the
pipewire context.modules configuration section.
If a node suggests a graph rate that is not in the list of allowed
rates, find the closest matching rate in the allowed rate instead of
just using the default.
When playing a file with a rate of 352800 and allowed rates of 44100,
48000, 96000 (default rate 48000) this will switch the graph to 96000
instead of the default 48000, which requires less resampling.
We checked above if the param is supported and return -ENOENT already.
When we actually go enumerate the params but don't have any, return 0
and not an error.
Fixes wireplumber#370
By default, buffer negotiation favours the default property values of
the output node. Make this configurable and reverse this logic when the
output is a driver.
This makes it so that a stream connecting to a source will negotiate
with the preferences of the stream and not the source.
An example is a stream that wants 4 buffers from v4l2-source, because
v4l2-source has a default of 4 buffers, this will always result in 4
buffers, ignoring the preference of the stream.
Just like the optional build, make all field parsing optional. This
will leave the fields with their default values if they are not parsed
from the param.
We can then remove our custom functions and use the generic ones in
various places.
