AudioBuffer::read_from() only replaces data within the given
range (offset .. n_samples + offset) leaving the rest of the
buffer untouched.
With in-place processing, where the same MIDI buffer is used
for input and output, each sub-cycle must only clear the
processed range, while leaving the rest of the buffer
untouched.
MIDI playback used samples instead of usec.
MIDI capture used time-stamp from previous cycle.
buffer-size changes were not applied to MIDI port latency
When a session is loaded, click_io->set_state is called twice.
setup_click() is called when the engine re/starts, and
possibly again from Session::set_state.
During session construction, Port connections are not directly
made. Port::set_state just creates a list, which is later
applied by Port::reconnect from Session::hookup_io.
However, the second call to IO::set_state() calls IO::ensure_ports
again. Since the port already exists, this calls
Port::disconnect_all (while holding the process lock).
Even though the port is not connected at this point in time,
this triggers a ARDOUR::PortManager::connect_callback which
is emitted from the Audioengine when the process-lock is released.
While IO::set_state() continues to set Port::state, and fill
the Port::_[ext_]connections lists, this data is invalidated
moments later when the engine resumes and ::connect_callback
calls ARDOUR::Port::port_connected_or_disconnected.
The solution is to simply not call Port::disconnect_all
if the connection is not yet made (Session::InitialConnecting)
On windows this is still limited by the timer resolution, but
it's a start. This is mainly intended to be used with NDI or
other external sources without actual audio hardware.
This correctly sets audio port I/O latency using the
portaudio API.
Per MIDI device port settings are not completely implemented.
En/disabling MIDI devices or setting custom MIDI port latency
is not functional as-is.
