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.
This allows our a2dp-source (sink endpoint) to report delay to the
remote source endpoint. Setting the "Delay" property is already
implemented, but by failing to configure DelayReporting, bluez rejects
the property change.
Idle the source when no packets are received and resume when new packets
arrive.
Add a stream.may-pause property to pause the stream when no packets are
received during the timeout window.
Make sure the rtp.streaming property is updated correctly and as soon as
we get the first packet.
Fixes#4456
Reorganize some code to separate the creation and sending of the SAP
message.
Check if when the node changed, we have an actual change in the SDP
before we send BYE and the new SAP message. It's possible that nothing
changed, for example when the node simply changed state or an unrelated
property.
