In some cases copying an instance requires an explicit
set_state() call (e.g. copy internal plugin state). This is
done by calling `set_state(other->get_state())`.
::get_state() produces XML as matching current_state_version.
(not loading_state_version).
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.
In the log output, the error would look like:
[ERROR]: Export initialization failed: Exception thrown by AudioGrapher::SndfileWriter<short>: Could create output file (.../export/something.wav)
Add the missing negation.
But it would perhaps be better phrase the message differently so it not
just hints so strongly towards a file system error preventing file
creation.
Perhaps something like "Failed to initialize sound export to %s"?
Many formats use ExportFormatBase::SF_Double which incorrectly would end
up in the default "we don't handle anything else within ardour" branch.
(It happened to work correctly anyway, since ExportGraphBuilder::SFC
handled the "magic" value 1 the same was as the "error" value 0.)
For correctness, use the "magic" value 1 for double.
The libsndfile format was masked with 0xf instead of the usual
SF_FORMAT_SUBMASK. It seems like the end result generally was correct
anyway, since no supported format used subtypes that used the low bits
for anything else. Most formats use SF_FORMAT_PCM subtypes. (Only Ogg
Vorbis uses a subtype, but that happens to have 0 in the low bits and
ended up in the "this will never happen branch" ... which happened to
work too.)
This could however be a real problem when SF_FORMAT_MPEG_LAYER_III with
value 0x82 is supported ... unless worked around in some way.
I don't see anything anywhere that could stuff anything in the high bits
of the subtype, so this trivially fixed by using SF_FORMAT_SUBMASK
correctly.
Apply SF_FORMAT_SUBMASK before comparing with the expected value.
It seems like it accidentally used to work correctly for all supported
libsndfile formats anyway.
But: It seems unfortunate to hardcode Vorbis in this place. Other
formats with quality control would have to be added to the list too. It
would be nice to do use something like has_codec_quality ...
Before, an export format with an invalid enum value (for example in the
Encoding id) would crash Ardour with:
unhandled exception (type std::exception) in signal handler:
what: unknown enumerator FOO in PBD::EnumWriter
That kind of error can happen if a new type is introduced and users
switch back to versions without it.
Instead, catch such exceptions while loading a format, log an error, and
skip the format - similar to how other format loading errors are
handled.
DeviceInfo (bindings file) can include explicit motorized
and threshold settings. These values, when specified, are
used during load_bindings() during set_state and overwrote
any user customization.
Furthermore showing the GUI invalidated any prior setting
by explicitly calling binding_changed, which re-applies.
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.
