Adding/removing the Monitor section changes port-connections,
a port-engine is needed to establish connections.
Ideally we'd allow this and queue for connection changes. This
will however require deep changes.
Also toggling the monitor-section on/off/on w/o engine can later
result in failure to register ports. Due to lack of engine-signals
not all shared_ptr<> port references are dropped.
lili93's session (#ardour) triggered this w/jackd 512fpp:
Drag/Drop copy a latent plugin from one track to another while rolling.
The GUI-thread as well as the auto-connect thread concurrently call
jack_recompute_total_latencies(). The auto-connect thread holds
a process lock while doing so. The GUI does not use any mutexes.
This randomly deadlocks in libjack.
backtrace: https://pastebin.com/6m3KGhWS
Empirically this decreases gc-spike duration (worst-case) by a factor of
two and speeds up the average gc-run by a factor of over 4 (depending
on the amount of memory used by the plugin).
This also tweaks fade behavior when the latency changes to prefer a
x-fade when possible.
This new variant does not support concurrent re-allocation and
execution. Hence the auto-connect thread needs to take a lock before
updating latencies (actually there's no need for an explicit update with
built-in backends, so this case remains to be updated further)
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.
The general goal is to align transport-sample to be the audible frame
and use that as "anchor" for all processing.
transport_sample cannot become negative (00:00:00:00 is the first audible
frame).
Internally transport pre-rolls (read-ahead) before the transport starts
to move. This allows inputs and disk to prefill the pipeline.
When starting to roll, the session counts down a global "remaning preroll"
counter, which is the worst-latency from in-to-out.
Each route in turn will start processing at its own output-latency.
Route::process_output_buffers() - which does the actual processing
incl disk i/o - begins by offsetting the "current sample" by the
route's process-latency and decrements the offset for each latent
processor. At the end of the function the output will be aligned
and match transport-sample - downstream-playback-latency (if any).
PS. This commit is a first step only: transport looping & vari-speed have
not yet been implemented/updated.
Session::post_playback_latency() sets the actual route latency,
so that playback latency notifications need to come after capture-
latency (backends follow the same rule: capture first).
NB. Session::initialize_latencies() was already using the correct order
* centralize signal_latency_at_***_position to processors
* update initial-delay/roll-delay when processor order changes
* consolidate signal-latency calculation: use the same method
for processor-changes and session's post_playback_latency.
* include relative output-delay in roll-delay
* fix capture processor position & optimize stem-export latency
(roll-delay fixes pending Route:roll() update)
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
When forking regions, copying playlists or saving snapshots we do not
have a reference to the track and cannot use the track's name as basis
for the new filename like Editor::fork_region() does.
A cloned midi region's name is based on the original region name.
This prevents endless addition "name-1-1-1-1-1-1-1-1.mid", adding
to the region's basename.
