Currently ::roll() may actually be a ::no_roll() under some circumstances.
This can also happen during count-in:
transport_stopped () == transport_rolling()
and during latency-preroll:
Global session-transport speed != 0, some tracks already roll,
read data from disk and feed latent plugins.
but other non-latent tracks or busses don't roll and still have to
behave like the switch from no_roll() to roll() has not yet happened.
This changes the game WRT to monitoring as well, previously, Route:roll()
called Route::no_roll_unlocked () for conditions outlined above.
Now Track::no_roll_unlocked is called and in some cases wrongly clears
the buffers before the signal hits the disk-writer. (more work is needed
related to 61f8e53b)
On the upside this also fixes an issue with MidiTrack::no_roll not keeping
a lock while pushing data into the step-edit-ringbuffer.
This is also a step towards consolidating all entry points:
::roll(), ::no_roll(), ::silent_roll() in the Route class.
Individual Routes cannot split the process-cycle in no_roll(); roll()
by themselves. Each of the calls will flush output buffers (and offset
port-buffers). If a route feeds another route the inputs of the other
route will only see partial data.
AudioPort::get_audio_buffer() can offset the buffer simply by offsetting
a pointer. This allows to get an offset buffer for a given port.
For MIDI there's no such concept. A method writing to a MIDI buffer
which is backed by a Port can at best offset it by the global port-buffer
offset (static Port::port_offset), but not by the individual target port's
offset.
This allows to push latency upstream and delay the source
in case the destination has a longer latency.
Also add a signal to notify the Session in case this happens, intended
to queue a latency-recompute.
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.
This is mostly to see if there'll be any problems when merging these changes into Mixbus. I'm guessing there'll be some conflicts in these projects (and a lot more to follow...)
After over 17 years of honorable service to the Ardour Codebase.
ClickBox and AutoSpin are retiring into the git nirvana.
We're glad for the duty, decency, reliability, dignity, respect which
these classes brought to Arodur and look back in gratitude on their years
of service.
PS. First one to say "cruft" will be fired.