We can't move the mix_list ports to the free_list like that because the
elements in the list use a different list to link together. Also, we
don't need to free those ports at all because they will be freed when we
move the port_list to the free_list.
Keep a list of active ports in the port_list. These are all ports added
with add_port and not yet removed. When a port is removed, move it to
the free_list and reuse the port later when needed.
Update a mix_list of ports when a valid io is set on a port. This then
makes it possible to more efficiently and safely iterate the ports in
the processing loop.
It's not used anymore because it does work so well.
The problem is that while it transparently proxies param enums on
ports to peers, it fails to emit events when those peer
params change in a way that would make the enum result change as well.
This makes it quite hard to use this correctly.
Instead of doing (cycle+1) & 1 for output ports, simply swap the io
areas depending on the port direction (0 = input, 1 = output) and
just to cycle&1 for all ports.
When node.async is set, make the node async.
Advertize SPA_IO_AsyncBuffers on mixer ports when supported. Set a new
port flag when AsyncBuffer is supported on the port.
When making a link and if one of the nodes is async and the linked ports
support AsyncBuffer, make the link async and set this as a property on
the link. For async nodes we will use SPA_IO_AsyncBuffers on the mixer
ports.
Nodes that are async will not increment the peer required counters. This
ensures that the peer can start immediately before the async node is
ready.
On an async link, writers will write to the (cycle+1 & 1) async buffers
entry and readers will read from (cycle & 1). This makes the readers read
from the previously filled area.
We need to have two very controlled areas with specific rules for who
reads and who writes where because the two nodes will run concurrently
and no special synchronization is possible otherwise.
These async nodes can be paused and blocked without blocking or xrunning
the rest of graph. If the node didn't produce anything when the next
cycle starts, the graph will run with silence.
See #3509
This is to iterate params that are common to all ports, such as
EnumFormat or the supported IO areas. Mostly interesting for mixer and
splitter nodes so that we don't have to create a new port just to query
things.
port_set_io with SPA_IO_Buffer can be used to enable/disable a port
when the node is running and so the node should make sure the io update
is synchronized with the processing loop.
Use spa_loop_invoke to make sure the mixers handle the port_io updates
correctly.
Setting buffers or a format also needs the port to be disabled so add
some checks for this in the mixers.
uint32_t i;
for (i = 0; i < SPA_N_ELEMENTS(some_array); i++)
.. stuff with some_array[i].foo ...
becomes:
SPA_FOR_EACH_ELEMENT_VAR(some_array, p)
.. stuff with p->foo ..
Add avx mixer to test and benchmark
Rework and unroll the avx mixer some more.
The SSE one is 10 times faster than the C one, The AVX is 20 times
faster. The SSE2 function is 5 times faster than the C one.
Let the mixer functions accumulate the intermediate results into a
larger size variable and then clamp to the final precission. This avoids
distortions because of intermediate clamping.
Although the access pattern of the reads are no longer sequential, the
writes are sequential and we don't need to read intermediate values.
Together with the avoided clamping this is probably faster overall.
Add a unit test for the various cases.
Add an EMPTY chunk flag to mark a piece of memory as 'empty'. For audio
this means silence.
Use the empty flag to avoid mixing 0 samples.
Set the empty flag in output buffers on audioconvert.
When there is no input, mix up to a quantum of data. Otherwise we might
send too much data to the next node and cause a delay if it does not
handle this.
pipewire will allocate buffers aligned to the max alignment required for
the CPU. Take this into account and don't expect larger alignment.
Fixes a warning in mixer-dsp when the CPU max alignment is 16 but the
plugin requires 32 bytes alignment for the AVX2 path (that would never
be chosen on the CPU).
See #2074
Parse the quantum_limit parameters and use this to scale the buffers so
that they can contain the maximum allowed samples instead of the
hardcoded 8192 value.
See #1931
