~Session calls AudioEngine::remove_session(), which fades out,
then unsets the session, and then in libs/ardour/audioengine.cc:460
```
session_removed.signal(); // wakes up thread that initiated session removal
```
Session d'tor continues, and calls Port::PortDrop(), which
unregisters all ports one at a time.
Concurrently, AudioEngine continues, and calls PortManager::silence_outputs
which gets all ports first (!), and then iterates over them.
There is a race condition which can lead to
DummyAudioBackend::get_buffer: Assertion `valid_port (port)' failed
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
This also allows to disable the resampler, effectively disabling
varispeed support, for the benefit of adding no additional latency.
By default 2 * 16 samples latency are added, due to port-resampler,
this is not desirable if Ardour is used as mixer only.
In all years of using these assert()s never triggered. Besides
there are valid_port() tests in other strategic locations that
are not periodically hit in realtime context.
The connection was stored by the Port where it was initiated from:
1. Connect A to B
2. Disconnect B from A
(1) Port A remembers the connection to B
(2) Port B does not know about the connection from A
Since disconnect is initiated on port B, port A still retained
the connection information.
When restarting the engine, Port::reconnect() reestablished the
connection.
This is only relevant when libardour's own connection information is
used. e.g. the session is closed without engine, or when re-starting
the engine while the session is open.
This allows to get public latency ranges for any port
including Ardour's latency-compensation as well as including
any latency induced by external JACK applications.
It is mainly useful to detect ambiguous latency and to
forward public port latency of connected ports.
Previously Ardour only announced processor latency.
Routes that had additional latency to compensate for those
have not published this delay.
This is of no concern with internal backends, however with JACK,
Ardour reported incorrect *individual* port-latencies of
routes that perform PDC.
Since public port latency now includes delay-compensation,
some extra work is required to unset it before recalculating
latency of paths that include external ports.
If there are multiple connections, one might fail due to missing hardware,
but the rest could still be valid.
An easy way to reproduce this was to route "mackie control out" to a device
and to the Midi tracer port. When you opened the session again, connection
from the "mackie control out" to the device would not get restored because
the Midi tracer port does not exist at session start.
This most likely caused other issues with connections when changing backends.
Previously there was only a PostDisconnect() signal.
When a port connection is made directly e.g. recorder_ui.cc
r->input()->audio(..)->connect(...), or when connecting
using an external jack control app, Ardour::IO is not informed.
no IOChange::ConnectionsChanged signal is emitted and
Track::set_align_choice_from_io() is not called. This leads to
incorrec capture alignment.
To minimize signal emission the static global PostDisconnect
is changed into a per port ConnectedOrDisconnected signal.
IOs subscribes to signals from owned ports only.
This is needed to update the GUI (mixer-strip I/O buttons)
when the engine is re-started with different I/O.
When Port::reconnect() cannot re-connect the port (e.g.
because the corresponding hardware port is missing), the IO object
needs o be notified -> PostDisconnect() -> IO::disconnect_check.
While the port-manager re-establishes and re-connects port,
port_manager->running() == false, and Port::get_connections()
returns the Port::_connections set (not actual engine connections).
So _connections.clear() has to be called synchronize it with
the actual engine connection state.
Ardour's "pbd/i18n.h" needs to be included last,
after any include that may indirectly pull in getext or libintl.
For that reason "pbd/i18n.h" must not be used in header files either.
Generator ports (like TransportMaster slaves), should not be
re-sampled when vari-speeding. Instead the Timecode/Clock should
directly use the engine-speed.
For this to happen, they need to be special-cased: no re-sampler
latency, direct access to engine-buffers.
Previously Ardour used a /local/ per track vari-speed mechanism.
Now that the disk-reader is a latency-compensated processor, the speed
of each disk-reader would need to be maintained locally, offset by each
disk-reader's output latency. Furthermore each disk-reader may
produce a different number of samples, depending on its global alignment.
This commit introduces port-data resampling directly at the engine-level:
Up/down-sample all input ports at the beginning, and down/up-sample output
port-data using the inverse ratio at the end of the session's process
cycle.
The session itself is unaware of the speed-change, and only needs to
handle transport speeds {-1, 0, +1}.
This also allows for aligned cue-monitoring and vari-speed recording,
and also pitch-shifts synthesized MIDI along.
Robin Gareus
Paul Davis
luz paz
Todd Naugle