Logging Data in Bela.io

ryjobil

If writing uint16_t then why not just use std library ofstream directly?
(or c-style fwrite)

Either way converting to 16 bit int to avoid writing meaningless bits is the most basic and simple form of data compression. Maybe the .wav format file has a purpose after all :-P It assumes everything after bit 15 is noise.

int16_t word;  //signed int seems more convenient than uint16_t
float sample = SOME_FLOATING_POINT_NUMBER;

word = (int16_t) lrintf(sample*SHRT_MAX);

giuliomoro

ryjobil If writing uint16_t then why not just use std library ofstream directly?

WriteFile provides the convenience of not having to worry about threaded write to disk, as that is handled by the class. It's not rocket science, so that could be easily implemented for any other write, still it is convenient for the use it was originally conceived for (data logging).
Ideally, we'd want to extend WriteFile to support libsndfile files and arbitrary types, but that is very low priority for us, though pull requests are welcome 🙂

ryjobil

giuliomoro WriteFile provides the convenience of not having to worry about threaded write to disk,

This makes sense now that you pointed out this aspect of it and I see the value in making use of this class if I want to add an audio recording function. Eventually it would be nice to be able to record to wav files to disk.

The first application I have in mind is to augment a looper effect with the ability to save and recall loops from prior sessions. Raw binary logging is probably adequate for this, but then there is always the idea it would be nice to have a simple workflow to download and import wav or FLAC files into a DAW.

What I had envisioned was a simplistic scheme to schedule auxiliary task in which a buffer is written to disk when a certain buffer size was full. The quick 'n' dirty approach is to open an fd with flags O_NONBLOCK | O_WRONLY and let the OS handle buffering (although technically one should probably use the raw write() function). Then you can keep writing even if everything from the last call hasn't finished writing to disk. Honestly at the moment I can't think of any way this would actually be "dirty", but I concede there is a lot I may discover along the way if I were to attempt to implement it. You only get in trouble if the disk I/O is so busy/constrained it can't keep up with the average amount data being written. There is no coding magic that can fix that type of problem 🙂

giuliomoro

ryjobil You only get in trouble if the disk I/O is so busy/constrained it can't keep up with the average amount data being written

You may find out that disk performance degrades with CPU usage, even if you try to do explicitly buffered writes. Or at least that was my experience, which is why I ended up adding my own buffering later in WriteFile.

ryjobil

giuliomoro disk I/O

Yeah, this is loosely used to mean the whole process: CPU usage, bus speeds, memory speeds, etc.

Anyway I see the value in expanding WriteFile as a basis for adding more output formats...before I derail this thread too far (sorry @swadhin if I'm adding confusion and making it harder for you to sort out what's useful here). It looks like it will be worth my time to understand how the class works & add libsndfile functionality there before doing my own thing.

Erwan

Hello all,
I would like to create a wav file from the audioRead function, is that possible ?
But I don't understand how to make a wav file from this :

float val = audioRead(context, n, ch);
file1.log(val);

Thank you.
Erwan.

giuliomoro

this is not currently possible through WriteFile. One option is to use libsndfile directly: http://www.mega-nerd.com/libsndfile/

Another option, if you don't need to reuse the file immediately (e.g.: if you are storing it for logging data to disk): store it with WriteFile as kBinary and then use Matlab or Audacity or Sox to convert the raw data to an audio file.

Third option, if you want to re-open the file from within the program, you can still use WriteFile with kBinary, and read the raw data from disk into a buffer that you then playback.

Yet another option is to use puredata and [writesf~] to write the file to disk.

All of these are sub-optimal and what is really needed is actually having WriteFile use libsndfile to write a valid audio file to disk. It's not a huge effort, I am happy to provide guidance if anyone is up for the task.

Erwan

ok, thanks giuliomoro !

I will use the second option for the moment.
WriteFile function works well.

Erwan.

bvk

Any advice on time accurate logging of sensor data coming in a Pure Data patch on the Bela?

I've tried something using timer and text objects but am getting mode switches when logging and underruns when writing .txt...

giuliomoro

[writesf~] would give you "time accurate" and tread-safe logging of sensor data coming into Pd, but it may be a bit too heavy if you are logging all 8 inputs at once ...
[text] and the likes are likely to cause trouble because they'd try to write to file from the audio thread.
If the above doesn't work, we'll need a custom solution in the libpd C++ wrapper file.

What sampling rate should the logging be at and for how many channels? Only analog inputs or also audio I/O ?

bvk

I'm thresholding the sensor data to capture onsets from an FSR, I would need to log those as time accurate as possible. I would use three analog inputs, time accuracy preferably towards the microsecond range, and no audio I/O logging. I would expect around 3000 onsets for each channel in a single session.

Thanks for the quick reply!

giuliomoro

bvk towards the microsecond range

then use [writesf~] : it will be sample-accurate.