I see on the forum that the blocksize can be set to arbitrary large numbers, maybe restricted to powers of 2. I'm using bela with CAPE. At 48kHz sample rate, when I try with -p240, I can see that context->audioFrames is set to 240. However, when I try with -p480, context->audioFrames is set to 476. What could be causing this? Is there any other setting that I should change to use blocksize of 10ms at 48kHz? context->audioSampleRate is set to 48000 in both 5ms and 10ms cases.
Stick to powers of 2, anything else is largely unsupported.
Why do you need exactly 10 ms ?
Thanks for the quick response! There's an audio postprocessing algorithm that works at either 5ms or 10ms. For the 10ms usecase, I can set the blocksize to 256. I cannot set it to 512 as the algo has only 480 samples in the output. With 256 sample blocksize, one frame will be used only to buffer the data and the other frame will be used to buffer the data and run the algo. So I'm using only half the cycles available for processing on bela. Not an ideal scenario as I see the CPU usage is close to 50%. Further changes to the algorithm can push it beyond 50% and cause underruns.
When you set the blocksize above 32 (on CTAG BEAST) or 64 (on CTAG FACE) an extra thread is spawned where the hardware blocksize of 32/64 is buffered to the user-specified blocksize.I think that only works in multiples of the hardware block size, which explains the behaviour you are observing in terms of actual blocksize.
If your algorithm runs once every 480 samples and there's no way to tweak that, then indeed running it in the audio thread will cause dropouts while the cpu usage is still far from 100. In that case I suggest rolling back the blocksize to the maximum hardware block size for your board and then implement the buffering in your user code, running you processing in a dedicated real-time thread. See the FFT examples in Audio/ for an example of how that can work.
giuliomoro Thanks for the suggestion, I will look at the FFT example.
