This is mainly for RME RayDAT that has a fixed buffersize of 16k:
dev_name : hw:HDSPMxc2f6c5,0
channels : 36
min_rate : 32000
max_rate : 192000
min_bufz : 16384
max_bufz : 16384
min_nper : 4
max_nper : 512
However nperiod configuration determines the effective latency
regardless.
This is similar to https://github.com/jackaudio/jack1/blob/master/drivers/alsa/alsa_driver.c#L476-L486
When export is done, nothing a MIDI-only track will reduce the gain ("goto midi" inside
DiskReader::run() and the "declick-in-progress" state will be permanent
This was just a proxy for libs/evoral/evoral/Event.h. Note that the #define
that controlled allocation that was at the top of the removed header is
replicated in the Evoral header, so there are no semantic changes
This fixed a false-positive "ambiguous latency" warning for
MIDI busses:
MIDI track -midi-> MIDI Bus w/instrument -audio|midi-> master
The master-bus only has audio inputs, so the MIDI Bus'
MIDI out is left unconnected. Its latency does not matter,
it can float freely.
Previously it was assumed to be zero. So the MIDI Bus' input
playback latency range was [0, master-bus playback-latency].
The issue remains if a track is selected by a "fit-selection" action second
last track covers the whole trackview. Then when scrolling one track up, the
huge track disappears and a smaller track follows, that covers a lot less
space.
-> Proper redraw of the track view is still needed.
jack2 can process in parallel with calling a graph-order or
latency-callback, so Ardour takes a lock to update those in sync.
Yet jack2 can also block while port-registrations happen,
and concurrently emit latency-callback from another thread..
Port and connection changes always imply a latency_callback from
the engine. Worst I/O latency is updated directly in
Session::update_latency() which is called from
AudioEngine::latency_callback.
Explicit subscriptions to route->output()->changed() is not needed
to update the worst I/O latency.
Only set_block_size() needs to to update the I/O latency when
the buffer-size changes.
The backend may call update_latency() while at the same time
the auto-connect-port calls set_worst_io_latencies().
The latter already holds the process-lock, so update_latency()
first needs to acquire it, as well. If one already holds the
_update_latency_lock, one must not ask for the process-lock.
---
Previously Ardour's connection manager first took the process_lock
and then waited to the _update_latency_lock.
Meanwhile jack calls latency_callback(), takes the
_update_latency_lock and waits for the process_lock.
Classic deadlock.
