A complete reimplementation of AudioGrapher::SilentTrimmer::process to support
trimming the beginning and end in the same processing block
Fix export with trim end enabled to actually trim silent frames
Only add silence to beginning or end of export data if data was written
Should resolve: #6412
Unlike many of the other uses of the term "frame" this is actually returning
the index to the first sample in the interleaved frame that contains
non-silence.
With end trim enabled, the only case that would successfully export was if
there was at least some samples above the silence threshold in the last export
processing block.
The issue was that the EndOfInput flag was not being passed to
AudioGrapher::SndFileWriter::process which would then call sf_write_sync and
emit the FileWritten signal to start post processing. Fix that by always
passing the EndOfInput flag in the last export process cycle.
Related: #6412
This allows a TmpFile pointer to be either a Sync or Async (Threaded)
writer. As result we must be able to handle both RT and non RT processing.
Still, post-processing (normalization and encoding) should always
happen faster than realtime (freewheeling).
Since jack does not allow a client to change to freewheeling from within
the process-callback, the async-writer disk-thread FileFlushed is used
to initiate post-processing.
* add a threaded TmpFile Writer
* update API calls to that process_export_fw() can be used as
process_function
The idea is to re-use export infrastructure from normalization:
export to a tmp-file and then encode target formats after that.
uselib is no longer implicit (inherited by .use). This is still incomplete,
some uselibs for non-linux variants may be missing.
bld.is_defined("HAVE_XXX") also no longer works and will have to be
changed (I think to bld.env["HAVE_XXX"]) in countless places.
This reverts commit 9a281963e1.
audiographer cannot use symbols from libardour (cyclic dependency)
(only headers only are ok)
"DebugBits ExportAnalysis" symbol break windows and unit-test builds.
lib/libfftw3f.a(apiplan.o):apiplan.c:(.text+0x430): multiple definition of `fftwf_destroy_plan'
This is because static symbols in a .dll have no fixed address and
are mapped when loading the dll. Static functions in .exe do have a fixed
address.
With a header-only implementation the functions are provided
libardour.dll and ardour.exe
