The backend holds `_port_callback_mutex` while disconnecting ports.
In some cases disconnecting a port can drop the last reference
resulting in a port-deletion from the connection handler.
This in turn will eventually aquire the `_port_callback_mutex`
and deadlock.
This is now circumvented by using atomic operations instead of
taking a lock to set the `_port_change_flag`.
The flag is also used to trigger a latency update in some cases,
atomic is preferable to taking a lock to set this flag.
--
Full bt: https://paste.debian.net/1184056/
Short:
#1 in pthread_mutex_lock ()
#2 in ARDOUR::PortEngineSharedImpl::port_connect_add_remove_callback()
#3 in ARDOUR::BackendPort::~BackendPort()
#4 in ARDOUR::DummyPort::~DummyPort()
#6 in ARDOUR::DummyAudioPort::~DummyAudioPort()
#7 in boost::checked_delete<ARDOUR::BackendPort>(ARDOUR::BackendPort*)
#12 in boost::shared_ptr<ARDOUR::ProtoPort>::reset()
#13 in ARDOUR::Port::drop()
#14 in ARDOUR::Port::~Port()
#15 in ARDOUR::AudioPort::~AudioPort()
#17 in ARDOUR::AudioEngine::add_pending_port_deletion(ARDOUR::Port*)
#20 in boost::detail::sp_counted_base::release()
#37 in ARDOUR::PortManager::connect_callback() at libs/ardour/port_manager.cc:788
#38 in ARDOUR::DummyAudioBackend::main_process_thread() at libs/backends/dummy/dummy_audiobackend.cc:1018
This allow to restore original engine port-names as set
by the backend. ALSA MIDI, CoreAudio, CoreMIDI and PortAudio
drivers can provide human readable physical port names for
some devices.
* PortEngine::available() implementation
* AudioEngine::connected() wrapper
Eventually we may re-introduce PortEngine::available along
with a libardour internal port-engine.
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.
This hopefully fixes an issue with port-registration (new session)
being skipped because PortAudioBackend::available() still false
until the first callback.
For drivers that correctly report latency values(ASIO) this should result a
much closer alignment of audio in a loopback test. Measurement and
adjustment may still be needed, especially for non-ASIO drivers.
Testing with the RME HDSP Multiface and Yamaha AG06 using ASIO drivers results
in maximum offset of a couple of samples.
