It combines all latency from one direction and sets it as the latency
for the other direction.
Also keep only one latency value per port, in the object.
Rework the param handling a little.
Keep properties for ports. Use this in the client and port info.
Trigger the latency callback when the port latency changed.
Update the port latency when it changed.
Trigger a recalculation of the port latency when the peer port
latency changed.
This makes the latency update from a port propagate through the
pipeline.
Implement a port recalculate latency method that takes the min
and max latency of all peer ports and sets that as the new port
latency.
When a link is made, let the output and input port recalculate
latencies.
Pass latency param in audioconvert.
Add a new latency param that contains a latency object.
The latency object contains the min and max delay from a port to
the terminal sink/source. It is also possible to express this
delay as a fraction of the quantum to avoid having to recalculate
the latency every time the quantum changes.
When we add a new listener to an object, it will emit the full state
of the object. For this it temporarily sets the change_mask to all
changes. Restore the previous state after this or else we might not
emit the right change_mask for the next listener.
Consider the case where one there are two listeners on an object.
The object emits a change and the first listener wants to enumerate the
changed params. For this is adds a new listener and then triggers the
enumeration. If we set the change_mask to 0 after adding the listener,
the second listener would get a 0 change_mask and fail to update
its state.
This is an attempt of breaking up the documentation, currently spread across
several pages. We're left with a few high-level topics with various things
grouped underneath those.
Further refinement is necessary, but this can now be done in incremental steps
over massive reworks.
While doxygen can handle markdown pages, support for it is very limited:
markdown pages can only be included as a whole page, they get an automatic
title (custom titles are possible but aren't standard markdown) and it's not
possible to use \subpage without messing with the markdown again. Any markdown
page will thus end up as separate item in the doxygen output, not really
suitable for generating a good page hiearchy.
Let's switch the tutorial to use doxygen directly instead of markdown, short
of using code/endcode instead of markdown's ``` there isn't that much
difference anyway but it allows us to structure things nicer in the online
docs.
This matches the behavior of most applications - check environment variables
first, then fall back to the various built-in options (in our case xdg, /etc/
/usr/share, in that order).
This requires a helper script: doxygen doesn't differ between static methods
and static inline methods. EXTRACT_STATIC defines whether it parses *any*
static method but we're currently using all C files as input files as well. We
cannot convince doxygen to just parse static inline functions in header files
so for SPA we hack around this: meson passes the spa headers to a shell script
with simply copies those changed to `/* static */ inline void (foo)` and doxygen
then runs on those header files.
The result: we get all spa functions added to your doxygen output at the cost
of a few sed calls.
