This is a special case of an Internal Return processor
dedicated to the monitor-section. The main use-case will
be to collect signals from physical ports in a realtime-safe
manner (no connections or Port creation)
This is in preparation to move RoueUI::SoloMuteRelease
to libardour to reuse the implementation in various places.
This also prepares the solo logic for exclusive port-monitoring.
This allows for rt-safe monitoring, collecting data
directly from input-ports without requiring a dedicated connection
or dynamic ARDOUR::AudioPort creation.
This slowly un/mutes the direct monitor signal when listen state
changes.
Listen sends already fade in as well. However un-soloing still
hard-removes the listen send path.
ArdourButton draws a custom insensitive background, using
the color "gtk_background". This can conflict with gtk's
insensitive background color when using round-corners.
In rare cases it can happen that the GUI thread results in
a call to DropReferences(), while the backend (RCU) still has a
reference to the track and processes the track.
However the call to DropReferences, DiskIO processor will
have cleared the pointer to _track, leading to segfaults when
the processor runs.
Since the DIO processor is owned by the track, one cannot directly
pass a shared_ptr<Track>. That would keep the Track around forever.
However the DIO processor cannot exist without a track passing
a reference is acceptable.
The JACK API doesn't allow server calls from inside a server callback, even though JACK2 doesn't enforce this.
It would be nice to find a way to NOT call Session::setup_bundles() from every port registration callback, too.
Retain engine speed across stop/start/locate, so that it is
possible to run a loop at non-unity speed. User must
explicitly reset to 1.0 if default speeds are set to !1.0
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 is needed to update the GUI (mixer-strip I/O buttons)
when the engine is re-started with different I/O.
When Port::reconnect() cannot re-connect the port (e.g.
because the corresponding hardware port is missing), the IO object
needs o be notified -> PostDisconnect() -> IO::disconnect_check.
While the port-manager re-establishes and re-connects port,
port_manager->running() == false, and Port::get_connections()
returns the Port::_connections set (not actual engine connections).
So _connections.clear() has to be called synchronize it with
the actual engine connection state.
