Bela Audio Recorder

This is probably more complex than it needs to be.
You are never closing the file, that may be the reason why it is empty? Does the fillBuffer() function ever run?

Anyhow, this seems more complex than it could be. You could use a Pipe to send data reliably from the audio thread to the other thread. See here the documentation.

An example (untested) would be something like this:

#include <Bela.h>
#include <libraries/Pipe/Pipe.h>
#include <libraries/sndfile/sndfile.h>

const char* path = "./recording.wav";

AuxiliaryTask gFillBufferTask;
SNDFILE * outfile;
unsigned int gAudioFrames;
unsigned int gAudioInChannels;
float gAudioSampleRate;

void openFile() {
    SF_INFO sfinfo;
    sfinfo.channels = gAudioInChannels;
    sfinfo.samplerate = gAudioSampleRate;
    sfinfo.format = SF_FORMAT_WAV | SF_FORMAT_PCM_16;
    outfile = sf_open(path, SFM_WRITE, &sfinfo);
}

void closeFile() {
    sf_write_sync(outfile);
    sf_close(outfile);
    printf(".wav file written and closed\n");
}

void writeBuffer(void*) {
  unsigned int numItems = gAudioFrames * gAudioInChannels;
  float buf[numItems];
  while((ret = pipe.readNonRt(buf, numItems) ) > 0)
  {
    sf_write_float(outfile, &buf[0], ret);
  }
}

bool setup(BelaContext* context, void* arg)
{
  gAudioSampleRate = context->audioSampleRate;
  gAudioFrames = context->audioFrames;
  gAudioInChannels = context->audioInChannels;
  pipe.setup("sndfile-write", 65536, false, false);
  setupFile();
  if((gFillBufferTask = Bela_createAuxiliaryTask(&writeBuffer, 90, "writeBuffer")) == 0) {
    return false;
  }

}

void render(BelaContext* context, void* arg)
{
  // context->audioIn is the float* that points to all the input samples, stored as interleaved channels)
  pipe.writeRt(context->audioIn, context->audioFrames * context->audioInChannels);
  Bela_scheduleAuxiliaryTask(gFillBufferTask);
}

void cleanup(BelaContext* context, void* arg)
{
    closeFile();
}

ok that was a naming conflict between the pipe variable and unistd.h's pipe, brought in by Bela.h.
this compiles

#include <Bela.h>
#include <libraries/Pipe/Pipe.h>
#include <libraries/sndfile/sndfile.h>

const char* path = "./recording.wav";

AuxiliaryTask gFillBufferTask;
SNDFILE * outfile;
unsigned int gAudioFrames;
unsigned int gAudioInChannels;
float gAudioSampleRate;
Pipe gPipe;

void openFile() {
    SF_INFO sfinfo;
    sfinfo.channels = gAudioInChannels;
    sfinfo.samplerate = gAudioSampleRate;
    sfinfo.format = SF_FORMAT_WAV | SF_FORMAT_PCM_16;
    outfile = sf_open(path, SFM_WRITE, &sfinfo);
}

void closeFile() {
    sf_write_sync(outfile);
    sf_close(outfile);
    printf(".wav file written and closed\n");
}

void writeBuffer(void*) {
  unsigned int numItems = gAudioFrames * gAudioInChannels;
  float buf[numItems];
  int ret;
  while((ret = gPipe.readNonRt(buf, numItems) ) > 0)
  {
    sf_write_float(outfile, &buf[0], ret);
  }
}

bool setup(BelaContext* context, void* arg)
{
  gAudioSampleRate = context->audioSampleRate;
  gAudioFrames = context->audioFrames;
  gAudioInChannels = context->audioInChannels;
  gPipe.setup("sndfile-write", 65536, false, false);
  openFile();
  if((gFillBufferTask = Bela_createAuxiliaryTask(&writeBuffer, 90, "writeBuffer")) == 0) {
    return false;
  }
  return true;
}

void render(BelaContext* context, void* arg)
{
  // context->audioIn is the float* that points to all the input samples, stored as interleaved channels)
  gPipe.writeRt(context->audioIn, context->audioFrames * context->audioInChannels);
  Bela_scheduleAuxiliaryTask(gFillBufferTask);
}

void cleanup(BelaContext* context, void* arg)
{
    closeFile();
}

mpc I was also wondering when external power (such as a power bank supplying 5V) is connected to the Bela, am I right in thinking that after it boots up it automatically begins running the project?

That can be done by selecting the project you want to start at boot from the top menu in the Settings tab of the IDE.

mpc but I assume that the code requires some modification to accommodate the additional inputs for recording?

you have to use analogRead() instead of audioRead(), and be mindful of the difference in sampling rate (and hence the number of frames per block) between audio and analog channels as explained here.

Last, be aware that there will be a significant difference in quality between the analog in channels and the audio channels, see here for more.

mpc As using the same pipe causes issues but attempting to use two pipes (one for audio, one for analogue) causes errors when the code is running.

what error would you get? Two Pipes should work just fine, as long as you use two separate AuxiliaryTasks.

Using one Pipe is also fine, you should just make sure that you are sending data in exactly the same format and order as you are receiving them. In the example below I send audio first and analog second, and I receive them the same way. The while(1) with break is to make sure that if the thread didn't get a chance to run between invocations of render(), it gets a chance to run and empty the content of gPipe.

For instance:

void writeBuffer(void*) {
 while(1) {
  unsigned int numItems = gAudioFrames * gAudioInChannels; 
  float buf[numItems];
  int ret;
  if((ret = gPipe.readNonRt(buf, numItems) ) > 0) 
  {
    sf_write_float(outfile, &buf[0], ret);
  } else {
    break;
  }
  
  unsigned int numItemsAn = numAnalogFrames * numAnalogChannels;
  float bufAnalog[numItemsAn];
  int retAn;
  if ((retAn = gPipe.readNonRt(bufAnalog, numItemsAn)) > 0)
  {
  	sf_write_float(outfile, &bufAnalog[0], retAn);
  }
 }
}


void render(BelaContext* context, void*)
{
...
gPipe.writeRt(context->audioIn, context->audioFrames * context->audioInChannels);
gPipe.writeRt(context->analogIn, context->analogFrames * context->analogInChannels);
...
}

A few notes:

• the code above is thread-safe only as long as it runs on one CPU. If you were to port it to an architecture that uses multiple CPUs, you'd have to be a bit more clever
• if you can accept a (probably minor or insignificant) performance penalty, you could pack all the relevant analog and audio samples in a single buffer and send them with a single gPIpe.writeRt() call, which would simplify the writeBuffer() function and be thread-safe. If currently you are sending more data than you need (e.g.: you are sending all the analog channels, but you are only using 4), then this solution would actually save some CPU time, instead of causing a performance penalty, as you would reduce the memory that gets copied to the pipe.

If the SD card is formatted with a filesystem that your computer can read, then you can. If this is the regular Bela SD card you are talking about, it is formatted as ext4, which can only be read natively from Linux, though I remember there were some free drivers for Windows. There was also a solution for macos, but that would be a commercial ($$$) one. However, if you have a USB SD card reader, you should be able to read it from a Linux Virtual Machine running on macos, but that is a bulky option I'd say. One possibility is to store data to an external medium, e.g.: a USB stick.

The safest option is probably to never overwrite existing files. You use WriteFile::generateUniqueFilename(const char* original) to get a unique filename and make sure you don't overwrite the existing one. See here for details on usage.

Alternatively, what you could do is modifying your program so that it only creates the file and starts recording if a certain GPIO is in a certain state. So for instance, you could put a wire between the GPIO and 3.3V or GND when it has to be recording and then removing it before you boot the board in "read only" mode. Given how you are calling openFile() (which will truncate the previous file) from setup(), you wouldn't be able to use digitalRead(), but you'd have to use an arbitrary GPIO pin.

Ultimately, what should be implemented is this, so that you'd be able to write a file to the BELABOOT partition (which you can read/write from your host without drivers, given how it's FAT32) to prevent the file from running at boot. Or even better, repurpose The Bela Button so that if it is pressed before the program starts it disables running at boot for the current boot.

mpc I think potentially re-formatting the SD card (back-up everything prior) to a recognisable file system might be the way to go

it's not easy: Linux has to run from an ext4 partition, but it can access many other filesystems. You could instead add a partition on the SD card with a different filesystem.

mpc char generateUniqueFilename(const char path = “audioCh.wav”);.

what is this?

You'd use it like this:

char originalFilename[] = "my-file.wav";
char* uniqueFilename = WriteFile::generateUniqueFilename(originalFilename);

and then subsequently use uniqueFilename (and free() it when you are done).

mpc When you say 'subsequently use uniqueFilename' would you be able to elaborate abit on this?

I mean, in the reminder of your code use uniqueFilename and not originalFilename. You can free() it as soon as you no longer need it. Usually that would be as soon as you opened the file, as henceforth you'd be referring to it via the file descriptor. However, cleaning it in cleanup() is also just fine.

mpc I did reformat the SD card to this filesystem and then flashed the Bela image but unfortunately that didn't seem to work.

Flashing the Bela image on it will override any partitioning/formatting you may have done before. You should start with a flashed image and then add a FAT32 partition to it. I am not familiar with macos's disk utility, but it should be able to do this. Alternatively you can use fdisk on the board.

I want to be able to record audio signals without knowing beforehand for how long I will be recording. The recording time could be in the range of 10s of seconds to hours (assuming enough disk space exists). Ideally if the program where to crash I would want the recorded material to still be on the disk.

I saw this recording example but that writes into a single vector and then writes that to disk. For recording large amounts of time that would require a whole lot of allocation.

Then I found this code you wrote earlier: giuliomoro

Does sf_write_float actually write data to the disk or does that happen when sf_write_sync or sf_close is called? It seems like it does when looking at the libsndfile source but I'm not 100% sure. Assuming it does directly write to disk and disk space is infinite, I can use this code to record until infinity?