I tried setting DEFSENDVS, DEFDELVS to 16 as well, and everything seems to be working fine now.
(I would not recommend doing this in practice, though.)
Why wouldn't you recommend it? (I am assuming you were referring to changing the DEFSENDVS/DEFDELVS define values).
I agree that it would be nice to have the "internal/rendering" blocksize of Pd be a runtime parameter as well.
If I understand correctly, one would have to:
- Add a runtime flag, eg. -rendering-blocksize (as opposed to the existing
-blocksize)
- Modifying all the code depending on the DEFDACBLKSIZE to use the run-time
value instead. I guess one way to do this would be providing the value through a global function so that the value cannot be changed from anywhere but the startup code.
- Have the default value of this now modifiable rendering block size still
be 64 for backward compatibility
- Making sure that the io block size is always forced to be at least the
size of the rendering block size
- For alsa settings, add the additional values that can be set to the menu
for the io block size
Would that be enough?
As for the need for it, I would personally use it, I tuned my linux system to run at 16 samples but I cannot use such settings when I want to run Pd (I can with Bitwig and Bespoke synth). In general I think that nowadays it would be useful, considering linux and Pd can be run in all sorts of embedded devices that in turn are part of more complex signal chains (eg: guitar pedalboards) together with several other digital gadgets, with all the latencies adding up.
Also, if I understand correctly, this would improve the time granularity with control-rate objects and messages... even though on the other end it might increase the relative overhead of the control-rate processing compared to the audio-rate one.
Athos