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
The warning "samples per period does not match." never triggered.
Previously not being able to set the requested buffersize was a
fatal error.
This adds support for soundcards that only support msec.
e.g. recent HDA Intel via SOF (Sound Open Firmware)
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.
This fixes an issue with some soundcards e.g. "AxeFx III".
Device configuration fails unless set_hwpar() is performed
for the capture device before configuring the playack
device (half duplex is fine, too).
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
This adds a basic support to use multiple sound-cards, currently
limited to two devices: In/Out with shared settings.
Advanced setups still have to resort to using the ARDOUR_ALSA_EXT
environment variable
This is intended to prevent crashes when unregister_port() modifies the contents of these
two members at the same time that something else is iterating over them.
This can help when running with very low latency and the
initial process callback is [indirectly] expensive.
E.g. load a heavy session the a RPi4, initial setup can pull
in a lot of data, which blocks the bus.
In particular with the ALSA backend this can lead to poll timeout
which effectively stops the backend.
When recover() successfully re-initializes the device,
processing can continue just like after an x-run.
This can happen during initial session load of "expensive"
sessions (in particular on slow systems, e.g. Raspberry Pi)
usually with synths. Worker thread pulls in many external
files in the background which blocks the bus for a long time.
resulting in a poll-timeout.
