MP3 support was introduced in libsndfile 1.1.0 . It will be a simple
alternative to using external ffmpeg.
To avoid dependency on the new libsndfile or config-time checking,
hardcode the constants from sndfile.h . The actual availability will
have to be checked at runtime.
When selecting "Origin" for the clock, it is expected that it should
work like "Absolute", except measuring from the selected Origin.
Positions to the right of origin should be positive.
However, recently, it got negated. As playback progressed, time got more
and more negative. Fix that by negating again.
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.
The region itself has no time_domain property, changing the time-domain
is done by changing the domain of the region length. undo/redo hence
emite a Length PropertyChange signal.
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.
