Flushing of recorded audio files

Tracktion Engine
1

Hi,

I have a scenario where I’m reading the audio file being recorded from another process/program. This works well in general; however I would like to be able to affect how the audio file is flushed to disk. In particular, it would be very useful if the WAV header was flushed to disk immediately so that I can open the file on the other side without having to wait for the first audio block to be flushed.

I managed to do this by patching the AudioFileWriter constructor:

AudioFileWriter::AudioFileWriter (const AudioFile& f,
                                  juce::AudioFormat* formatToUse,
                                  int numChannels,
                                  double sampleRate,
                                  int bitsPerSample,
                                  const juce::StringPairArray& metadata,
                                  int quality)
    : file (f), samplesUntilFlush (numSamplesPerFlush)
{
    CRASH_TRACER
    f.engine->getAudioFileManager().releaseFile (file);

    if (file.getFile().getParentDirectory().createDirectory())
    {
        const juce::ScopedLock sl (writerLock);
        writer.reset (AudioFileUtils::createWriterFor (formatToUse, file.getFile(), sampleRate,
                                                       (unsigned int) numChannels, bitsPerSample,
                                                       metadata, quality));
        writer->flush();  // <----   Added this line
    }
}

While this works, I would prefer not having to patch the tracktion engine source code. Is there any other way?

Also, the flush interval is defined as a constant in the same file (numSamplesPerFlush), it would be nice if it was a variable that could be changed from the “outside world”!

Thanks
Erik

2

Also, perhaps more important: when the transport calls the changeListenerCallback to announce that recording has stopped, have the recorded audio files already been flushed to disk? Or is there a potential race?

3

This feels a bit iffy to me…
Can I ask what the use case is?

This kind of thing will only work with WAV files but how are you syncing access to the file? I.e. when do you know that the file has grown?

I don’t really like the idea of people relying on internal behaviour. I can see cases where we actually write to temporary files before transferring them to the final file e.g. for ensuring the ends of multiple files recorded at once align. This may be possible by truncating WAV files but we’ll need a method which works with all our recording audio formats.

Having said that I think flushing the file before it starts getting data is probably ok and I think the file will be complete before the transport lister gets called (as that’s async).

4

I can see why you would be hesitant to make any guarantees in what I realise is a pretty niche case!

From our perspective though, we don’t necessarily need a general solution, we just need a way to solve a very concrete problem. If there are better ways to achieve the same result, I would be happy to try that instead!

So, basically the Tracktion Engine fills most of our needs – it is really nice to not have to implement audio/midi synchronisation, recording, scheduling etc! But one thing we do need is to analyse the recorded audio data while it’s being recorded — locally or by chunking the audio and performing the analysis in a cloud service.

Reading the file as it’s being written seemed like a simple and straightforward way (and is indeed how we’ve successfully been doing it in the past, before Tracktion Engine came into the picture). But obviously it could be done in other ways as well!

What would you recommend?