Setting a format does not automatically mean making a wav file.
Instead, check for the extension on the output file name and when we
can't find any good containet, use the same as the input file.
This makes more sense than doing `spa-resample test.flac -r 44100 test.wav`
and ending up with a FLAC file named test.wav. Or
`spa-resample test.flac -r 44100 -f s16 test2.flac` and ending up with a
wav file named test2.flac.
During negotiation, ensure that possible_caps exists before calling
gst_caps_intersect_full(). Sometimes possible_caps seem to be NULL which
cause the GST_IS_CAPS assert to fail.
The reason for the occasional NULL possible_caps during initial
negotiation is unknown, but this is also possible during renegotiation.
The handle_format_change() may be triggered before the next create(),
win which case we have not yet discovered in the streaming thread that
we are in the NOT_NEGOTIATED state. We should guard against this
possibility as well.
Because we don't know the stream state at the start of streaming, if
clients are deciding to connect on the basis of this flag, they will
never connect if we default to true. So let's be optimistic by default
and we'll find out on timeout if there actually isn't data to receive.
Some of the tools would like to connect to the manager socket first
because they are manager style apps. They however completely ignore any
of the configured sockets in the config and assume everything is the
default.
Fix this by adding a remote.intention = "manager" to those apps. This
instructs the protocol to first try to connect to a socket with the
-manager extension before attempting the regular configured socket.
This makes things work when you have sockets configured in /tmp
and have remote.name = /tmp/pipewire-0 in the config.
We use the remote name as a suffix for the default server address and so
it should not contain any slashes. Take everything after the last slash
if there is one.
We keep on calling the drain event for as long as we are drained. The
application is supposed to inactivate the stream or provide more data
at some point.
Because we do this from the data thread, we use a non-blocking invoke.
If for some reason the event callback takes a long time we might place a
lot of these invoke calls into the invoke queue, which will then be
dispatched one after another (and cause more blocking or a burst of
useless invoke calls).
Avoid this by only placing one drain invoke call into the queue at a
time.
Fixes#4529
If a provider uses the stream API and pushes a buffer to the stream
after the stream is set to paused, the buffer_id of the last buffer
remains in the io.
If a consumer starts streaming in this state, the buffer_id of the old
buffer is still in the io. The consumer receives a stale buffer_id and
may discard the buffer. Now the buffer is lost, since it is still marked
as busy on the producer.
This can be reproduced by starting Weston with the PipeWire backend and
repeatedly restarting a GStreamer pipeline that connects to the Weston
output. Eventually Weston won't be able to dequeue buffers since the
lost buffer is still busy.
Clear the buffers in the io when the buffers are cleared to avoid
sending an old buffer_id to the consumer.
The videoadapter always exposes the EnumPortConfig parameter. If no
converter is loaded, the EnumPortConfig parameter doesn't return a
parameter.
In this case, the client-node in the PipeWire server returns -ENOENT for
the EnumPortConfig, which in turn causes WirePlumber to fail the object
activation and it won't be able to create a link for the object.
This happens since Commit b57375ba85 ("stream: enable videoadapter in
all cases"), since now the videoadapter is always added. Before that,
the EnumPortConfig parameter was just not exposed and linking worked.
Running another client that ignores the error codes for missing
parameters (e.g., pw-dump) hides the issue, as the EnumPortConfig result
is cached as successful with 0 parameters and accessing the cache
doesn't return an error code.
Return the same PortConfig for EnumPortConfig as for PortConfig to fix
this.
The JACK2 maintainer would prefer to use a new port flag to mark the
MIDI2 capability of the port and keep the port type as MIDI. Add the
proposed flags to the API.
If we register a MIDI port with the MIDI2 flag, promote it to UMP.
Expose v1 MIDI ports with the MIDI DSP property again.
If we see an UMP port, set the MIDI2 flag on the port.
This is functionaly equivalent to what we have. Old jack midi ports will
now however not have the UMP DSP format but the old MIDI format so that
we can, in the JACK API, make a distinction between MIDI1 and MIDI2 ports.
Do not add/connect the profile for unconnected devices.
This fixes the issue where a previously paired ASHA device
would show up in the pavucontrol output device list even
when not connected.
We only need to switch between the converter ports and the follower port
when we switch between passthrough. Avoid emiting remove of the (non
existing) follower ports when the mode changes from none to DSP at startup.
If the rate is 0/0, converting nsec to ticks doesn't work and will
result in 0 ticks, and it is not possible to convert ticks back to a
timestamp.
This can be reproduced by connecting a GStreamer pipewiresrc to a
libcamera node. The libcamera-utils has a rate of 0/0 and the
pipewireclock won't be able to determine a correct time with that. This
error was caused by Commit 89993a3cc6 ("gst: enable the pipewire ticks
as a clock source").
Fix this by using the nsec as ticks and setting the appropriate rate.
This was added in error (88873e295b) but
we discussed it in !2180 and it turned out CFLAGS="... -fstrict-aliasing"
was set in the environment, overriding the earlier -fno-strict-aliasing
already set in meson.build (which we're keeping here).
That is, when -fno-strict-aliasing is in-effect, there's already no
need for -Wno-error=strict-aliasing (as the warnings aren't emitted), but
if there *is* a need for a -Wno-error=strict-aliasing for a user, it
means they're (likely unintentionally) enabling strict-aliasing and we
certainly want to make them aware of that.
