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
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
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
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.
Always reevaluate the rate matching even when we did not change the
follower state.
It is possible that we were a follower from some node with the same
clock and now become a follower of a node with a different clock. The
follower state doesn't change but we need to activate the rate matching
logic in that case.
Fixes rate matching in pro audio (playback) when capture and playback
are moved to another driver.
Variables enclosed with @ are replaced with the value of the variable.
The sink.name should remain @DEFAULT_SINK@.
Escape the enclosing @ to prevent substitution of DEFAULT_SINK with an
empty string while generating pipewire.conf.
We first need to do the setup, which we start when setting the Format
param.
This causes the module to unload when starting pavucontrol because it
tries to start the record in the wrong state.
See #3778
After we set the format, probe if we can do EXPBUF and enable/disable
the ALLOC_BUFFERS flag on the port.
This should gracefully handle the case where EXPBUF is not available.
Fixes#3821
When we try to alloc buffers but EXPBUF is not supported, make sure to
clear the alloc_buffers flag so that the caller can try again with
allocated buffers instead.
See #3821
If the manager gave us a different channel count than we had by
default or configured, assume everything is AUX channels.
Also handle the case where the manager is sending more than our
MAX_CHANNELS channels.
Move some of the tracking code for the DLL to where it is used.
Add resync.ms (default 10) option at which we give up rate adjusting
and instead do a hard resync. This results in a jump in the position
of the graph clock.
When we get a node info about our own state, we can use the active state
of the node to decide if we are running or not.
Otherwise, we will try to hide ports from JACK clients that suspend
(while still active).
See #3794
We can increase the MAX_LATENCY again if we increase the amount of
buffers when we are using a small buffer.
Normally we ask for 4 * quantum-limit as the buffer. This should be good
to use 1 buffer and quantum-limit as the quantum with enough headroom
to not run out of buffers.
If we are however using less buffer-frames we need to be careful and
allocate an extra buffer. Imagine using a buffer of 4096 frames, we can
support a quantum of up to 2048 frames if we use 2 buffers.
See #3744
Half of the buffersize is not enough to support as a max-quantum, we
need to divide by (4 * frame_scale) to allow some headroom and account
for the DSD scaling. We do the same calculation to suggest a buffer size
using the quantum-limit.
See #3744
When the filter has no format property, just enumerate all possible
framerates. Handle error case where the filter has the wrong type.
Makes gst-launch gstpipewiresrc ! video/x-raw ! fakesink work.
See #1793
Actually count the number of frame fractions we add. If we added 0, we
don't have any supported framerate that intersects with the filter and we
try the next frame size.
See #1793
When we are notifying the application of changed params, don't emit any
changes applied to the params from within the callback with
pw_stream_update_params(). This will be done after we complete the
callback.
This also avoids reseting the change counter so that we don't
accidentally think we updated the formats param when we simply changed
some other params.
Unknown transports visible in DBus usually belong to a different
sound server instance that is talking to BlueZ.
Explain this in the warning message that we log, so that people can more
easily understand why things are not working.
When freewheeling we will immediately schedule a new graph cycle when we
get a process call because the graph completed.
When the process call is not done, because of some xrun or
because some node was removed that causes the graph to fail completion,
The next cycle will happen after a timeout.
This timeout was calculated as the ideal wakeup time (after a quantum of
time) and would accumulate for each timeout. The result is that the
timeout ended up far in the future and would stall the freewheel driver
for a long time.
Fix this by always setting the next timeout to wakeup time + freewheel.timeout
seconds. Also add a config property for the timeout (10 seconds, like
jack2 by default).
