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.
Querying available buffersizes and sample-rates requires access
to the device. Almost all ALSA devices are limited to
a single user-space application so we unconditionally try
to request access to the device.
jack1 (which is Linux only) does not have a jack_client_stop_thread
API, and expects the application to call pthread_join().
This fixes an issue when the application is compiled using jack2 headers
but the application later runs using jack1's library.
PBD::Transmitter is neither thread-safe nor rt-safe. This likely
fixes a crash on macOS when process-threads are started.
Many threads simultaneously enter coreaudio_process_thread() and
log a message calling `PBD::info << .. << endmsg` simultaneously.
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.
Found via `codespell -q 3 -S *.po,./share/patchfiles,./libs -L ba,buss,busses,doubleclick,hsi,ontop,ro,seh,siz,sord,sur,te,trough,ue`
Follow-up to 364f2f078
If connecting ports using the port-engine fails,
ardour forgets the connection.
Internal backends only produced an error if a port was already
connected, when using ::connect (handle, other), but
ignore already existing connection when using port-names.
Various ports are connected twice when the engine connects
at session load. This worked fine for as long as the engine
was never stopped (saving the session asks the port-engine),
but failed when the engine went away and internal representation
is used.
"While 'atomic' has a volatile qualifier, this is a historical
artifact and the pointer passed to it should not be volatile."
Furthermore "It is very important that all accesses to a
particular integer or pointer be performed using only this API"
(from https://developer.gnome.org/glib/2.68/glib-Atomic-Operations.html)
Hence initialization of atomic variables is changed to also use
this API, instead of directly initializing the value.
This also fixes a few cases where atomic variables were
accessed directly.
see also libs/pbd/pbd/g_atomic_compat.h
PortAudio uses what it calls 'default suggested latencies' but in callback streaming mode, they can result in wildly inaccurate buffer sizing (e.g. the user requests a buffer size of 128 but PortAudio actually instructs ASIO to use a much bigger size).
What we do now is to improve PortAudio's suggested latency calculation by basing it on the actual buffer size requested by the user.
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.
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.
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).
