This was disabled in 15b4c58e as under various circumstances Gstreamer
pipelines would mmap the DMABufs, which can be very slow in various cases.
One typical example of that is screen casting using a dedicated graphics card.
Thus we only want to use DMABufs if the peer element advertises support for
`GST_CAPS_FEATURE_MEMORY_DMABUF`, ensuring no mapping will happen if we
set the format accordingly.
This allows pipewiresrc to be used with DMABufs for fully accelerated
pipelines or in combination with a download element such as `gldownload`[1]
without regressing the commit above. The `gldownload` approach mirrors
what webrtc (Chromium/Firefox) does, but without duplicating the
functionality into pipewiresrc.
While on it, also implement dmabuf negotiation according to
https://docs.pipewire.org/page_dma_buf.html with the modifiers
`DRM_FORMAT_MOD_INVALID` and `DRM_FORMAT_MOD_LINEAR` in order to allow
dmabuf negotiation with more modern clients, including Gnome-Shell.
1: for now use something like `glupload ! glcolorconvert ! gldownload` -
`gldownload` does not support importing DMABufs yet but `glupload` does.
Dictionaries are by default printed in their insertion order.
This is unergonimic when comparing properties created by different
clients, as they may insert them in different orders.
When we clear the buffers on an output port when we clear the port
format in suspend, also clear the buffers shared by the peer input
port mixers because else they would reference old stale buffers.
Fixes#2914
Incompatible changes between ROC v0.1.X and v0.2.X require
adjusting the ROC modules' code. The largest change is going
from `roc_address` to `roc_endpoint`. There is also a breaking
change, the removal of `local.ip` parameter from module-roc-sink
as `roc_sender_bind()` has been removed.
The API usage was modelled after https://github.com/roc-streaming/roc-pulse
See #1757Fixes#2911
Add a `fd` property to `GstPipeWireDeviceProvider` so it can be used
with fds obtained from e.g. the camera xdg-desktop-portal.
This is needed so apps like Cheese or Camera can easily implement the
camera portal.
Quoting the commit introducing `GstPipeWireCore`:
```
Make all sources in the same process with the same fd share the
connection to the server. This makes it possible to set the same
fd on multiple sources/sinks and have them all use the same
connection, like when capturing multiple monitors from screencast
with the portal.
```
Do the same for `GstPipeWireDeviceProvider`, so it can share a
connection with device sinks as well. This will be needed for fd based
connections introduced in the next commit.
Further more it allows some cleanups.
1: 70652d1a37
Add support for PIPEWIRE_DEBUG=3,foo.bar:5 to set a global log level in
addition to specific topics.
Previously it would have to be done with *:3,foo.bar:5, which would not
really set a global level but all topics to the custom level of 3.
The function was broken since the log topics were added.
Use the logger to init a topic with the given name and check if
there was a custom level for the topic.
Add a new config section that can contain a set of commands to run after
starting.
There is only load-module available now but it can be used to remove the
dependency on pactl when starting the server.
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.
