These might be the values that PA would have chosen anyway, but make it
clear that Ardour is in control ... and will let the user control
"everything" with the buffer size.
This will also change the internal backend name, so it will miss the
previous 'config' setting '<State backend="Pulseaudio" ...'` and the
session file's '<EngineHints backend="Pulseaudio" ...'. But that is no
big deal after upgrading. Especially after the backend has been broken
for some users for a while.
It adds some new strings to translate. These strings might be so rare
and technical that it is a bit pointless to translate them. But let's
stay consistent...
pa_threaded_mainloop_wait might wake up for several reasons. And there
is no point (but possibly harm) in moving on before we have verified
that PA actually is ready to receive our write without overflow.
ae3c8b19c6 and 03a17df68c reworked the transitions to and from
freewheeling. Some of it seems to have been experiments that tried
several things out, and generally it seems to have worked. It left some
commented out code. Clean that up.
The draining was introduced in ae3c8b19c6, apparently as an experiment
doing several changes. But the drain is outside the loop where
freewheeling changes, so the fix must have worked for other reasons.
There doesn't seem to be any benefit from draining at that point. The
stream is already empty. If not, we could have flushed it.
Draining right after uncorking will conceptualy create an intentional
underflow, even though it isn't reported as such. PipeWire seems to
(something like 6-12 months ago) have regressed in handling of that grey
area, causing that *underflow* to cause a request for too much data, and
thus causing constant *overflows* and unusable playback.
This change makes PulseAudio playback work for me again.
In all years of using these assert()s never triggered. Besides
there are valid_port() tests in other strategic locations that
are not periodically hit in realtime context.
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.
When exporting long sessions with freewheeling, pulseaudio
may meanwhile suspend the corked audio device. The "FAIL_ON_SUSPEND"
option then prevents ardour to uncork it after export, and the
audio-backend is halted.
This potentially breaks various assumptions (e.g. no resampling,
fixed buffersize) when the stream is moved to a different device.
Then again it's pulseaudio, which is unsuitable for pro-audio to
begin with.
