Force filter graph reconfiguration in setup_convert.
When adding/removing filter-graphs, only perform setup when we were
already setup, otherwise we will do this in setup_convert later.
Don't do channelmix_init when we were not setup.
Deactivate the filter-graphs when we suspend.
Fixes#4866
Improve the spa_ump_to_midi function so that it can consume multiple UMP
messages and produce multiple midi messages.
Some UMP messages (like program changes) need to be translated into up
to 3 midi messages. Do this byt adding a state to the function and by
making it consume the input bytes, just like the spa_ump_from_midi
function.
Adapt code to this new world. This is a little API break..
Use bits to capture the work that is needed. We clear the bit when
we added the stage, when all bits are cleared we have nothing more to
do. This avoids having to check multiple bookleans.
Make a helper function to calculate the destination buffer. When all
bits are cleared, we can use the output buffer.
Ensure we have at least a `.` after `audioconvert.filter-graph`, so we
don't try to read past the end if it does not exist.
Also document in the param name that an index is expected.
We don't actually have to store the ramp parameters so allocate them on
the stack and then use them to generate the sequence.
Make it possible to generate a sequence into a custom buffer as well.
Make sure we use the right rate (the graph rate) to calculate the number
of samples when converting from time to samples.
There is no need to encode the potential format in the format.dsp of
control ports, this is just for legacy compatibility with JACK apps. The
actual format can be negotiated with the types field.
Fixes midi port visibility with apps compiled against 1.2, such as JACK
apps in flatpaks.
Keep per graph latency. Sum all the graph latencies together and keep
this around as the process-latency.
Refactor the port latency setter. Make a function to recalculate the
latency of all other ports. Take into account the graph latencies.
Update the port latencies when the total graph latency changes.
First do the essential properties to set up the node, then set up the
node and then parse the params. The params might do some setup that
relies on a completely configured node, such as emit events.
Move the param enumeration code out of the main enum function.
Emit node events after completion of the set_param functions to ensure
we only emit things once.
Parameter values read into a 512 byte long buffer, which is insufficient
for medium to long filter-graph parameters.
Increase the buffer to 4096 bytes to give some wiggle-room.
Because we advertize on out ports that we support DYNAMIC data, we need
to read the data pointer directly from the buffer and only fall back to
our cache (mmaped) pointer when it is NULL.
With DYNAMIC data, the peer element (mixer-dsp) directly copies the
input data pointer into the buffer data in the processing loop in order
to avoid a memcpy when there is no mixing needed.
When there is no data and the buffer is mmapable, try to mmap it. Unmap
again when clearing the buffers.
Use the mmaped data pointer of the buffer when processing.
The audioconverter starts in Convert mode, so make sure it goes to the
None mode before we attempt to reconfigure ourselves.
Also remove the ports on audioconvert when going to None mode. This used
to somewhat work because we configured it in DSP mode without any
params, which is like None without ports.
Use per port allocated memory so that we can easily increase the size
and add more buffers. This is necessary when we add filter-graphs that
require more ports.
Use a simple free/active linked list for the filter-graphs and insert
the new filters in the right position in the list. Then simply copy the
list to an array for the processing thread.
when reconfiguring, set up all the filters again because the number of
channels might have changed.
When parsing the graph, parse the input and output port names into
a separate string array. This was we can keep them around when
setting up the graph.
Instead of setting up the graph right after loading it, do the graph
setup when we activate the graph. This makes it possible to pass the
input channels to the filter-graph and let it create the right amount of
plugins and ouput channels.
When setting up the graphs in the audioconverter, pass the current
number of channels as the input to the graph and keep track of the
channels that each filter produces.
This way we can also load a custom upmix or downmix graph, for example.
Depending on the direction of the conversion, we run the resampler
before or after the channelmix. This means we need to use the channel
count before or after the channelmixer instead of always using the
channels after channelmixing.
Fixes#4595
Partially revert 86af9de739
The PortParam does not give enough information to derive the direction
of the converter. If the converter is configured in convert/convert
there is just no way to know when to output a quantum or not.
Fix this by doing a quick probe of the follower and then pass the
direction to the converter.
See !2227
Report the "fractional" part of the resampler delay in
spa_io_rate_match::delay_frac, in nanosamples (1/1e9 sample) at node
rate.
The delay values are best reported in units where it is clear what the
clock domain is, so report the value in fractional samples instead of
nanoseconds. Conversion to ns is also just dividision by the appropriate
rate.
The delay is always expressed in samples at the output rate of the
resampler. For input streams we need to convert this to the expected
input rate.
Make the delay reporting in playback streams more accurate.
Make sure we only make the buffer for the follower larger when we
downsample because then we need to ask for more data from the follower
to fill up a quantum.
Never try to make the follower buffer smaller than the quantum limit.
The reason is that the graph rate could be decreased dynamically and
then we would end up with too small buffers.
See #4490
Load multiple graphs with audioconvert.filter-graph.N where N is the
order where the graph is inserted/replaced. Run the graphs before the
channelmixer.
Graphs can be added and removed at runtime.
Instead of recalculating what to do every cycle, we can prepare a
static schedule and just run that. We only need to reevaluate it when
something changes.
For input streams, first run the resampler and then the channelmix. This
ensures that the channelmix is run with the rate of the graph instead
of the rate of the input. This is nicer because rate and quantum align
with the graph and the sample accurate volume ramps will work as
intended.
For output streams, leave the resampler after the channelmix for the same
reasons.
