What I can detect is that the delay is always blocksize - 64. So yeah, a block of 64 or smaller promote no latency, but it increases to 64 samples for a 128 block, 192 for 256 block and so on... But I don't understand why as my intuition was that the latency should be the whole block of audio, and not that minus 64! Plus, I also find something weird about how it works... keep reading.

As the test signal, I have a sample count that starts counting from 1. When it receives a bang, the count gets reset to 1 and restarts. With that, I can print the input/output plus the subpatch block and check them out.

See the attached test file. It has a block of 128 inside the subpatch. When it is loaded, the subpatch waits 64 samples filled with zeros before it receives the sample count signal. You can click on the bang and redo the test and you may find that the subpatch can behave in the same way, where the first half of samples have not restarted the count yet OR you may have been lucky enough to sync them up and find that the subpatch's block actually starts counting from 1 as well!!!

Weird thing is that, even so, the output gets still delayed somehow.

I'm not sure if I can make myself clear or that you follow me, but the bottom line is that I'm still quite confused on how different block sizes behave in Pd! 

Where can I read more about this, has someone done similar tests and have figured this out completely?

Thanks