Also handle the relation between a node and the driver with pw_node_peer,
like we do with the links.
Because these are refcounted, we only make one peer for a node that is
linked to another node that is also the driver (pw-play -> sink) and we
save some fds as well as some admin stuff and overhead for the refcounts.
This in return then results in less problems getting all the refcounts
right when adding/removing nodes.
Currently, the user sets the Broadcast Code via an array of integers
in the config file. However, the Bluetooth Core Specification indicates
that it should be set via a 16 byte string. This commit replaces the old
implementation with the one required by the spec.
Tested the commit with the example provided in the Core Spec:
Broadcast Code: Børne House
Result from btsnoop log:
< HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) plen 31
...
Broadcast Code[16]: 000000006573756f4820656e72b8c342
The result matches the example given in the spec.
The mapoffset should be using in the mmap call as the offset.
Mapping the whole memory before the offset and then ignoring the part
before it seems like it can work but it actually has some problems:
1. some drivers (v4l2) use the mapoffset to calculate the buffer to map
2. we waste resources for mapped but unused pages.
The problem with the mapoffset is that it needs to be page aligned and
that used to be a problem in the past. Nowadays PipeWire no longer set
the mapoffset for any of the memory that it allocates.
In order to show metadata changes when monitoring, a sync must be
triggered just like it is done for other objects, to make sure that
`dump_objects()` is called some time later and the changed metadata
objects are shown.
Otherwise metadata changes would never be displayed unless there
was a change to a different type of object, whose event handlers
do trigger a sync.
Fixes#4053
Set the new IO Position after we removed the node from the old driver
and before the new driver is going to schedule the node. This makes
a little more sense.
Avoid freeing the old io Position area before the data loop has managed
to get a pointer to it. Queue a free operation that will be executed
from the main loop after the data loop has the io area.
Fixes a crash when stressing jack clients to switch between drivers.
Since commit f400ff2050 ("gst: Check for video/ caps before parsing
for info") JPEG support in the GStreamer elements is broken as JPEG is
not recognized as a video format anymore.
gst_video_info_from_caps is able to handle "video/" and "image/"
formats. Therefore, the check needs to allow "image/" too.
While at it, cleanup the formatting to make the check more readable.
The HAVE_GSTREAMER_DMA_DRM belongs to the inner brace, not the outer
brace, since the inner if statement is under HAVE_GSTREAMER_DMA_DRM.
While doesn't make a difference to the compiler, but confuses a reader.
Put the other brace under the HAVE_GSTREAMER_DMA_DRM.
We are not allowed to call free_link from the data thread because it
does free() and some pw_mem calls which should only be called from the
main thread.
To solve this, pause the core, queue a free_link operation on the data
thread, which will be scheduled after the previous remove_link operation
completes, free the link and then resume the core. Blocking and resuming
the core is necessary because we can't block for completion of the
invoke calls (the jack method is not allowed to block) and we must
ensure that nothing can happen with the memory (like reuse the mem_id)
before we have cleaned it up.
Fixes a crash in jack with create/destroy link stress.
When a link already exists, the link will fail and the proxy will be
destroyed and the pointer set to NULL. Avoid doing things with the NULL
pointer when cleaning up.
Construct this new class from both the src and sink to be able to share code
Consolidate the previous mess of open/close/start/stop into a single pair
of open/close functions in the new stream class
Add "encryption" parameter to bluez5.bcast_source.config entry in
the configuration file. This allows the user to control the use of
Broadcast encryption.
Most dependencies use meson "feature" options for optional
functionality. This allows people to disable them, if they don't want
them, through the power of tristate decision-making.
This particular dependency does something a bit more complicated than
can be described by simply passing feature options to the required
kwarg. It:
- tries to look for two different names of the dependency
- selects different version ranges, depending on the dependency name
- has a hole in the middle of the versions
Unfortunately, `required: false` for the first dependency isn't
equivalent to a tristate decision-making process. We have to manually
code the logic ourselves.
The problem is that when we look up the first name, we cannot pass the
feature option in because if the option is force enabled, then the
dependency lookup fails and configuration never tries to find the older
version instead.
But also, we can't just say it *isn't* required, because if the option
is force *disabled* but it is installed on the system, we still find it
and build against it.
One solution would be using meson 0.60's support for multiple dependency
names:
```
dependency('webrtc-audio-processing-1', 'webrtc-audio-processing',
version : ['>= 0.2'],
required: get_option('echo-cancel-webrtc'),
)
```
Unfortunately, this too doesn't work since we could end up detecting 1.1
(the hole in the middle) which is invalid.
Instead, we do a bit of checking for tristate values before deciding to
invoke `dependency()`. This lets us guarantee that disabled dependencies
are well and truly disabled.
Bug: https://bugs.gentoo.org/933218Fixes: #3678
This reverts commit cfeb937443.
Let's remove this for now, the node.rules and device.rules are mostly
used for this. We can add this later when there is a need for it.
Before loading the node or device spa plugin, evaluate the node and
device rules so that we can use them to configure the plugin properties
when it is loaded.
Add loader.rules that are executed right before the loader tries to load
the plugin with the info. This can be used to add or change properties
for the plugin.
One example would be to pass extra properties to the alsa or v4l2
plugin, even when this plugin is loaded by another process like
wireplumber.
Advertise support for the videotransform metadata.
Make a new meta.videotransform.transform property to configure the
desired video transformation in the metadata.
This makes it possible for a session manager or other rules to set
a custom transformation on the source.
See #4034
When bound_ctl info cannot be read this array elem info
is set to NULL in 'fetch_bind_ctl'. So when we iterate
the bound_ctl array we always have to check this.
Manage them like we do on the client and reuse logic. Make a node
function to safely add and remove a target.
Activate the targets from the process loop when we can be sure that we
can resume them. This avoids incrementing the pending state when we are
not going to be able to resume the nodes (like when the cycle is ongoing
and we have already been scheduled) and avoids glitches and xruns.
When a node is added to the poll loop, it can activate its own targets.
This is mostly for driver so that they have something to schedule and
can then activate the other targets.
Try to resume the target when it is removed and we are supposed to be
scheduled.
Also add targets to the target_list when the node is remote to make sure
the profiler can see the targets as well.
Keep the node in the INACTIVE state as long as the eventfd of the node
is not added to the loop. Skip nodes in the INACTIVE state from going to
the NOT_TRIGGERED status, which avoids scheduling the node.
Make sure we remove any local targets we have in a node when we export
it, we will receive new targets from the server.
This should eliminate any glitches when adding and removing nodes from
the graph.
See #4026, #2468
When for some reason we don't manage to transfer data from the source
or to the sink (timeout, scheduling problems..), try to do it when we
get a timeout to avoid xruns.
Latest alpine has gstreamer 1.24, which we should be compiling against because
the DMA_DRM code paths are not compiled with older versions. Unfortunately,
this is yet not in fedora 40.
Latest fedora is bumped just because. We should always test against latest
fedora and the previous ubuntu LTS, to make sure we support a relatively wide
range of system versions.
The translation between Pipewire parameters and Gstreamer caps is,
for compatibility reasons, ambiguous. Formats with linear modifier
are translated both in the legacy way as `format`, as well as
`drm-format`.
When finishing negotiation and setting caps, ensure that we:
1. set caps that the peer actually supports in order to prevent
negotiation errors.
2. fixate caps to DMA_DRM if both options are supported, using the newly
introduced helper, in order to prevent hangs.
While on it, add some small clean-ups that hopefully make the code
easier to follow, notably that `pwsrc->caps` and `pwsrc->possible_caps`
are only used during negotiation.
When support for modifier-aware DMA_DRM formats was added in f1b75fc6,
the translation between Pipewire parameters and Gstreamer caps was kept
compatible with the] non-DMA_DRM/legacy API by reporting format/modifier
combinations with linear or invalid modifier both as `format` and
`drm-format`.
In cases when a linear modifier ends up being negotiated, this, however,
resurts in non-fixated caps, preventing the negotiation to succeed.
Add a helper that allows to fixate such caps.
When the link on the pipewire side is destroyed, on video streams, buffers
are removed abruptly and there is no way this pipeline can be revived,
so let's post an element error to stop it.
On a normal shutdown, the pool is first set to flushing in change_state(),
so checking for the flushing state is a good indicator to know if this
is a normal shutdown or not.
See #1980
