Bela Audio Recorder

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.