Block size with Puredata on the Bela?

libpd's "logic" block size on Bela is decided at compile time and it is always going to be 16 (just like it is 64 on regular Pd). The blocksize you change at runtime (using -p, or the IDE) is the "hardware" blocksize (similar to the effect of the "blocksize" parameter in Pd).

sdaau Another thing that changed is the minimum block size, which is now 8 samples per block (vs the 64 of stock Pd/libpd). Actual block size can be adjusted at runtime using the -C command line parameter. Accepted values are 8, 16, 32, 64, 128, default is 16.

That is outdated, I just fixed it: the minimum block size is 16, as you found out from DEFDACBLKSIZE

If you want a "logical" block size of 64 in your libpd patch on Bela, you need to have a [block~ 64] in a subpatch. You normally want to also change the hardware blocksize to 64, or you will end up having dropouts with low CPU usage

sdaau Thanks for that - however, I just want to make sure - the doc says Actual block size can be adjusted at runtime using the -C command line parameter, however, if I run a PD executable from the command line, I get:

-p, that was another error in the wiki, now fixed.

sdaau n any case, I did some experiments with this, and it seems the -p setting takes precedence over whatever number [block~ N] might be set to

that should not be the case. Again, one sets the "logic" blocksize, and the other one sets the hardware blocksize, but you the one that will make you avoid dropouts is the hardware size.

also, libpd does not know about the -p setting, so if you have any internal measurement in Pd, such as the patch below, you would see no changes by changing -p.

Hi,

I want to change the internal block size and tried this:

git clone https://github.com/BelaPlatform/libpd.git
git submodule init
git submodule update --recursive
.... do your change to pure-data/src/s_stuff.h
make -f Makefile-Bela
make -f Makefile-Bela install

but the pure-data folder is empty - no src directory and no s_stuff.h file.

Help please!
Thx in advance, Klemenz;

Hi,

another question. Why does the block duration takes 1.437 ms with a block size of 16 samples? In my case it's even 1.542 ms. Shouldn't it take just 0.363 ms with a sampling frequency of 44100 Hz?

hmh, i tried [block~ 64] and the block size really changed to 64 but i lost all audio, I don't hear anything..

klemenz but the pure-data folder is empty - no src directory and no s_stuff.h file.

this probably means

git submodule update --recursive

failed somehow?

klemenz Why does the block duration takes 1.437 ms with a block size of 16 samples? In my case it's even 1.542 ms. Shouldn't it take just 0.363 ms with a sampling frequency of 44100 Hz?

how did you measure this?

klemenz hmh, i tried [block~ 64] and the block size really changed to 64 but i lost all audio, I don't hear anything..

Was that in the same patch /subpatch containing [dac~]/[adc~]? That's illegal (see [block~]'s help file for clarifications).

I got it running on block size 64. I had to switch into directory lidpd in order to run:
git submodule init
git submodule update --recursive

if you recompiled libpd with DEFDACBLKSIZE set to 64, then that's Pd's own buffer size. Setting smaller block sizes in Bela means that the libpd callback will effectively process data every 4 (with 16 samples per block) or 2 (with 32 samples per block) Bela audio callbacks (the render() function). This is the reason why I changed DEFDACBLKSIZE to 16 in the first place: to allow smaller latency. If you try to run Bela with a smaller block size than DEFDACBLKSIZE, you will also not be able to fully take advantage of the CPU: only 25% or 50% will be available to actually perform the computations in the two cases, respectively.

I just noticed that these lines:

		// send IMU values to Pd
		libpd_float("bno-yaw", ypr[0]);
		libpd_float("bno-pitch", ypr[1]);
		libpd_float("bno-roll", ypr[2]);

are adding one (Pd internal) block delay, because they are placed after the call to libpd_process_sys();, so their effect will only manifest itself at the next Pd block. Try moving them just before libpd_process_sys(), and see if it fixes it for you.

you should verify whether this latency happens only with the belaonyourhead code or also with a simple pass through example. In the former case, the issues is probably with the code in there.

ok, when I send a ramp of angles through the line tool to my external I got almost no delay. so the problem must lie within belaonyourhead. pheew, how to debug this? don't know where to start..

Upon closer inspection it would seem that the scheduling of the read happens much less often than advertised:

// Change this to change how often the BNO055 IMU is read (in Hz)
int readInterval = 100;
...
// in setup()
...
readIntervalSamples = context->audioSampleRate / readInterval;
...
// in render()
...
for(unsigned int tick = 0; tick < numberOfPdBlocksToProcess; ++tick)
{
...
         // this schedules the imu sensor readings
         if(++readCount >= readIntervalSamples) {
              readCount = 0;
              Bela_scheduleAuxiliaryTask(i2cTask);
          }
...
}

So reading happens every once every 44100/100 Pd blocks, instead of every 100Hz.

Try change the last few lines to:

         if(readCount >= readIntervalSamples) {
              readCount = 0;
              Bela_scheduleAuxiliaryTask(i2cTask);
          }
        readCount += gLibpdBlockSize;

You are the man! Thanks a lot, that did the job! It is really great how you run this forum here!
All the best, Klemenz