giuliomoro The fact that you can run it at 4 or 16 samples per block means that there has been some change to the code base (Pd's minimum is hardcoded to 64). I am wondering if there is anything else they changed and if the compiler flags are available. If they can run the Pd GUI at 16 samples per block on an embedded platform
ok, Ive found my source of confusion / missunderstanding ...
in PD -audiobuf 4 , doesnt set the buffer size in samples, it seems to set audio delay time (i.e. = 4ms)
(which at 44.1k, would be ~176 samples) , and block size is left at the default 64 samples
I didn't realise PD had essentially 2 buffer sizes?!
do you know how this interact?
Im assuming what the UI calls delay (and -audiobuf) is the audio buffer size, and then it chops these up into multiples of blocks size. and id assume/hope? that the audio buf is probably rounded to multiples of block e.g. 4 mS is rounded to 192? (or is it really 176 i.e. 64,64,48 .. that would confuse some processing in externals)
not sure why they have done this, just specifying a audio buffer size in samples seems easier...
is the block size, to help potentially reduce memory requirements when you have a large audio buffer?
anyway, given bela is just about ok on 64 samples, id say its actually performing as well , since im sure I wont get under-runs if i double it to 128.
re: vfp3/neon
I noticed when using xeon-config its actually saying its vfp3 , which contradicts the neon that i usually supply. and thought was correct for bela... I assume that gcc will take the one that is latter on the command line.
but thought it was a bit of a quirk.