Hi Roman,
I wonder if the blocksize of 64 is deeply baked into Pd or if it could theoretically be made configurable.
Pd's scheduler block size is a constant value (64 samples), defined as DEFDACBLKSIZE in "s_stuff.h".
In theory, you can change the #define in "s_stuff.h" and recompile Pd (and all externals, just in case some of them rely on it), but that's obviously not a good solution.
Now, the "callbackprocess" function in "s_audio_jack.c" checks if the Jack block size is multiple of DEFDACBLKSIZE. As you noticed, this breaks for Jack buffer sizes smaller than DEFDACBLKSIZE.
Actually, Pd's Jack callback implementation could use a small ring buffer for such situations. For example, if the Jack blocksize was 16 samples, Pd would call m_audio_callbackfn() every 4 blocks to fill the buffer. Note that you would still have 48 samples of extra latency, but at least sound would be working :-)
Generally, there is no way to get lower I/O latency than 64 samples in Pd without changing DEFDACBLKSIZE and recompiling.
I found the '-blocksize' flag, but it seems it only sets the blocksize for audio I/O and doesn't affect Pd's internal blocksize
Yes. "block size" is really a misnomer. At least it should be called "hardware blocksize" or even "hardware buffer size". It does *not* set Pd's scheduling block size, which is really fixed at 64 samples.
(and doesn't have any effect at all when running with -jack).
In the case of Jack, the hardware blocksize can't be set dynamically in the client. Instead, Pd obtains the value from the Jack server. The same is true for the sample rate, btw.