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.
The src can listen to RequestProcess commands and so gets the
node.supports-request = 1 property.
The play-pull example can both be a driver that listens to
RequestProcess or a lazy driver so set this in properties as well.
We can now remove the priority.driver property because automatic
priority selection will make us a driver or not.
With this change, video-src to video-play-pull will use lazy scheduling
with play-pull as the driver. video-play-pull to v4l2src will use
normal scheduling and video-src to video-play will also use normal
scheduling.
Collect the request scheduling flags and when there is a lazy driver,
set the lazy scheduling flag in its clock. This means that the driver
can expect RequestProcess commands to start the scheduling.
Pass the lazy scheduling clock flag to the node.
Make sure lazy scheduling driver have a higher priority than their
request drivers.
Take the current cycle times early and in all cases. We can use this to
get the current frame time for debugging purposes instead of the more
heavy jack_frame_time().
Rate limit the xrun warnings.
So that we can have different versions per FFT.
One possible optimization would be to split the complex number in
separate real and imag arrays. This would speed up the multiply
operations.
When we get a process callback from the capture stream but we can't
trigger the playback stream, simply consume the buffers from the capture
stream.
This can happen when the playback stream is not ready yet, for example.
If we don't consume the buffers that are ready, the converter might run
out of buffers and complain.
Clean up route/profile building a bit so that it is easier to add new
device profiles.
Use names instead of magic numbers for the routes.
Fix marking BAP set input route unavailable by error due to magic number
off by one.
The current implementation uses the slope variable S to define the
filter slope. Setting S = 1 results in a constant Q value of
sqrt(2)/2, or 0.7071, which is a good default value.
However, calculating alpha from the Q value instead, as done in
RBJ's cookbook [1], the filter shape can be changed which might
be desired for certain applications and provides flexibility.
Since the current implementation always defaulted to using S = 1,
make sure that configurations missing Q uses the same slope value.
[1] = https://www.w3.org/TR/audio-eq-cookbook/
Don't use TSS to store per-thread queues but keep a lockfree stack of
queues. We can then pick off a queue and write to that one and place it
back after use.
We need to keep the queues indexed by id in the stack because otherwise
we would need to compare-and-swap 128 bits (pointer + tag), which is
more problematic.
Because we keep the queues in an array and no queue is ever removed and
the array can only grow, we can quite easily just iterate the array
without a lock. Without the lock we also fix one of the potential
problems with ardour where the queue_flush thread is canceled while
flushing and the queue_mutex remains locked.
Because we end up with all queues in the array now, we can overflow the
fixed max amount of queues we can manage. When that happens, sleep for a
while and try again. This is a case where more than QUEUES_MAX (128) threads
are invoking at the same time and is rather unlikely.
There is also the queue overflow case which we now also must handle with
a retry. This potentially uses more eventfds but again this should be
unlikely and cause no further problems.
See #4356
