impl-metadata would not monitor for globals being removed.
This would cause stale metadata to remain in the
store, causing future objects on the same ids to have invalid data.
If a pipewire property has quotes, the DOT graph fails to be generated because
they are not escaped. This patch fixes this by escaping the quotes from a
pipewire property value before adding it to the graph
This changes avoids constantly reallocating the DOT data string every time
someting is added. We now always allocate a DOT data string of size 2048, and
we only reallocate by size * 2 if we need more data.
When we remove a global, we set NULL,NULL,NULL as its metadata. This
then results in the implementor of the metadata to emit the property
change event for the subject.
When we decide to propagate this event to the listeners we not only
need to check if the client can see the global but also if the global
was removed and this is a remove metadata event.
Fixes metadata remove events when a global is removed.
Add a MAPPABLE data flag that hints that the fd in the data is mappable
with a simple mmap/munmap. Normally, DmaBuf is not mappable like that
unless explicitly indicated with this flag.
Set the MAPPABLE flag on the DmaBuf from v4l2 and libcamera fd.
When asked, mmap the buffer memory in all cases when the MAPPABLE
flag is set.
This solves the case where v4l2 has exported DmaBuf and is streaming to
node A and then node B links but doesn't get automatically mmaped
memory.
Fixes#3840
Add props to the protocol_data and server. Instead of storing the
server_info, just add the relevant properties for the server to the
props.
When we get a new client, we can simply copy the server props to the
client props. This makes it possible to create specific servers later
that create clients with specific properties.
Use a subset of the context properties to create servers. We only need
the CORE_NAME for now.
When the server closes the connection in non-interactive mode, we need
to set the quit flag to avoid going into second mainloop_run() that will
just block forever.
See #3837
There is no need to start jackdbus via dbus service activation,
because this module is only interested in reacting to the jack server
starting/shutting down, it does not actually want to make use of jack
itself.
Avoid leaking buffers when freeing mix, in case the port was not cleared
properly.
These leaks don't seem to be occurring currently, but better be sure.
The remote end may destroy the port via client_node_port_update(),
before corresponding pw_impl_port_mix are released.
clear_port() removes all struct mix, but this prevents the
pw_impl_port_mix from being removed from io_map, which causes stale mix
ids be left in io_map, so we end up continuously allocating new io
areas.
Make lifecycle of io_map entries match port_init_mix/release_mix
exactly, separately from the lifecycle of the port and struct mix.
When freeing struct mix in port_release_mix(), make sure it corresponds
to the mix being released.
Props set on the node directly should also result in emission of changed
notify when required, just like we do for params set on the port.
This accidentally used to be done because stream_update_params()
unconditionally used to emit this for us. But commit
94cde3090e changed that.
Fixes#3833
If the property video.adapt.videoconverter is set the video stream
will be wrapped with the videoadapter from the videoconvert spa plugin.
This allows testing the videoadapter and videoconverters while
preserving the current behaviour. Later the chack for this property can
be dropped.
When a memblock closes its fd, have it emit signal to other memblocks
possibly sharing the fd, so they know it is now invalid.
When a memblock has an invalidated fd, it'll not allow mapping more
memory, nor match against fd searches.
This avoids bugs where kernel fd reuse causes already invalid memblocks
to be used. Generally, higher level code should make sure memblocks get
freed in right order so that this situation does not occur, but try to
keep mempool in consistent state regardless.
When the ringbuffer has too much data, do a resync or else we would just
have a huge delay and would try to resample to get back to the target
fill level.
If for some reason the proxy gets destroyed, we make sure to remove
listeners and forget the proxy pointer. We do not however delete the
target_link; we consider the proxy destruction as an error.
If another definitive state occured on the link (got to paused state,
got an error), then that event will be ignored. Else we consider it an
error.
Previously, on new node event, we registered a core sync. Linking was
attempted at core sync done but the node did not yet have time to
register its ports.
Only listen to new ports. This delays the linking attempt to when nodes
have had time to create their ports.
