Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
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.
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
Don’t call ::output() [here: SilenceTrimmer::process()]
with no data to process.
If (position + N * period-size) % chunksize == 0;
frames_left == 0 before the last call to ::output().
chunker.h:60 keeps the ProcessContext<T>::EndOfInput
flag and the SilenceTrimmer will already have done ‘in_end’ processing.
Use the gcc visibility attributes when building with the MinGW compiler(gcc).
GCC also supports the __declspec syntax but it will not compile at the moment
until the issues(which may not even be exactly the same issues as with MSVC)
are resolved.
This caused an export bug when:
a) normalizing
b) adding silence to end
c) having more than one channel
The sound was corrupted by repeating each jack frame as many times
as there were channels.
This avoids having to define define LIBFOO_DLL=1 all over the place. If we ever go with static libs we will
need to define LIBFOO_STATIC=1 but hopefully in some central location like the top level wscript.
Oh, and I also dropped support for gcc older than version 4.x because ardour will already not build
on such an old version.
