The delay-time itself can change arbitrarily, but the buffer-size
never shrinks.
If the buffersize grows it means that the new delay is longer than
the current one (or at least as large as any pending, not yet
active delay).
This is important for the mechanism that adjusts the read-pointer
to the new buffer-size.
There are still over a hundred left, but this addresses many already.
In particular @param references to undocumented parameters.
Most notably in audio_backend.h
* process only header files (API is supposed to be documented there)
(this resolves various inheritance and ambiguities, as well)
* Set pre-processor defines as a normal Ardour compile would
* Expand Macros (fixes issues with visibility defines)
This was based on Ardour-5 style "set custom latency of the IO", and
inform, override JACK-port latency compensation.
Ardour6: IO itself is no longer in control. This is abstracted by
IOProcessor.
In any case, this is to be superseded by bundling a-virtual-latency,
and allowing track playback offset (that has no additional
thru-latency for cue-monitoring).
Previously buffers were dropped, and data was not copied to
newly allocated buffers. As side-effect the read-offset was not
adjusted either.
The distance between read and write-pointer needs to be maintained
(delay does not change). This needs to be accounted for, when the
buffer increases while read->write wraps around the old (smaller)
buffer. Previously this triggered an assert (in line 180)
... which implies it has no MIDI input port(s) either.
This fixes behaviour caused by BufferSet::get...() returning a valid MidiBuffer because it was
based on using the _available count within the BufferSet, even though the _count value
indicated there was no buffer available (to match the I/O configuration of the Route).
