Theoretically this could be lock-free by using a queue of device
ports to be added/remove in sync in the process-callback, but
realistically adding/removing devices doesn't have to be rt-safe.
* PortEngine::available() implementation
* AudioEngine::connected() wrapper
Eventually we may re-introduce PortEngine::available along
with a libardour internal port-engine.
CoreMIDI ports are dynamic. When dis/connecting a device CoreAudio's
AudioHardware-PropertyListener triggers a callback which can
add/remove ports.
This can not happen concurrently with processing, but it may happen
concurrently with a user creating tracks using Ardour's UI
and/or session-load/setup.
Set accumulated capture-latency for physical-outputs
and accumulated playback-latency for physical-inputs
after Ardour is done setting all non-physical port latencies.
This will be needed for latency-compensation of the complete graph.
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
pthread-w32 does not support pthread_setschedparam() with
SCHED_FIFO and bails out. While pthread_create() simply ignores the policy
and sets the priority regadless.
This only affects ctrl-surface event-loops & AutomationWatch on Windows.
When starting ardour using the jack backend, playback only devices
currently do not get displayed. Mixing and Mastering only workspaces
with e.g. a single USB Dac should be a common use case. Take this use
case into account by adding them to the device list. Tested on Linux
with jack-alsa.
This hopefully fixes an issue with port-registration (new session)
being skipped because PortAudioBackend::available() still false
until the first callback.
