Don't mark a profile disconnected, if it still has active transports.
For BAP, emit device set changed events when transports come and go, so
that the SPA device can reconfigure accordingly.
These shouldn't be enabled by default, because they cannot be
autodetected, and if the configuration is not a supported one, they
produce loud BRRRT at 100% volume and ALSA errors.
Pipewire is designed to be built without strict aliasing enabled (as
evidenced by already hard-coding `-fno-strict-aliasing`). In case people
have strict aliasing warnings enabled by default in their build
environment, explicitly disable errors from those.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If the PCM is loaded directly using only api.alsa.path,
state->card_index may never be initialised, and then we end up opening
the wrong ctl device. Let's try a fallback for this case.
When the driver starts, save all previous node timestamps, not just the
previous signal time.
For async nodes, uses the previous timestamps in the profiler messages
so that we get stats with 1 cycle of delay instead of bogus values
because the node is still processing.
Fixes pw-top for async nodes.
When the driver node is destroyed (like when unplugging the cable) it
will drop/pause all of the follower ALSA nodes. This is something that
happens internally because of how the ALSA nodes work together, on the
PipeWire level, the nodes are still running and they will just be moved to
another driver.
The problem is that nothing will then start the nodes again after moving
it to the new driver. Fix this by keeping track of the desired target
state of the ALSA node and restoring that state when we detect that we are
paused when moved to a new driver.
Fixes#4401
Add a filter-graph info structure with the number of inputs and outputs
in the graph definition.
Use the input/outputs to update the number of channels on the capture and
playback streams when not explicitly given. Also copy over the positions
when they match the other stream and were not explicitly specified.
Fixes#4404
Add the overflow queues again. We can easily iterate atomically over the
overflow queues and flush them.
Overflowing a queue is quite common when heavy swapping is done and
should never cause a lockup, so allocate new queues as we need them. We
can share the eventfd with the main queue to avoid wastings fds.
The limit on the number of queues is then only for when concurrent
threads want to invoke things, so 128 is plenty enough.
If the peer announces an interlace mode then use it. Otherwise assume
that the video is not interlaced.
This also fixes a problem with caps negotiation:
If downstream reports caps with not fixated interlace mode, e.g.
"interlace-mode=(string){ progressive, interleaved, mixed }"
then without this, the caps handle_format_change() (in the pipewiresrc)
are not fixed and the source waits forever for the negotiation to
finish.
When a queue overflows we place the queue back in the stack and try
again. Because it's at the top of the stack we take exactly the same
queue and keep on looping forever if the other thread is blocked for
some reason.
Instead, mark the queue as overflowed and only place it back in the
stack when we have flushed it.
This avoids a deadlock when the main-thread invokes on the data loop
and blocks and when the data loop invokes on the main-thread and
overflows the queue.
Always listen on the receive socket. Find the stream with the given
stream_name of the packet and create it if it doesn't exist.
Also take the sample-rate, channels and format from the packet
parameters instead of the config.
Fixes#4400
Make SPA plugins from all the filter-graph plugins and use the plugin
loader to load them.
Because they are not in the standard plugin path in development, add
the module dir to the plugin path for now.
Make a plugin structure that is dynamically allocated for each plugin
and pass it around to the descriptor instance structures, so that they
all have access to dsp_ops without sharing a static pointer.
The problem with the static pointer is that the dsp_ops structure is
actually allocated in module-filter-chain's instance structure,
so it always points to the instance of the last filter-chain that was
loaded in the process. When this is unloaded, the other filter-chains
crash.
When we don't support EXPBUF according to the probe, the host will
allocate memory for us. We will then try to use USERPTR to import the
memory into v4l2.
If this is not supported, try to fall back to MMAP support, mmap the
buffers and memcpy the MMAP buffer to the host allocated buffers.
Instead of just probing with 2 buffers, probe with the MAX_BUFFERS and
remember how many buffers we received.
Some drivers (v4l2loopback) work with less than MAX_BUFFERS (8) and we
need to set the max number of buffers in the Buffers param.
