[PD] JACK and blocksize

[Giulio Moro]

On Bela we've been running with blocksize of 8 for a few years since 2016 and then we moved to 16 samples per block around 2018 I think (in both cases redefining the problematic constants). I think only in a couple of occasions this caused an incompatibility with a couple of externals relying on a hardcoded value of 64 instead of taking DEFDACBLKSIZE value from `s_stuff.h`.
Another drawback is the CPU penalty of running smaller blocks (which is what made us switch from 8 to 16 samples per block at the time). Smaller blocksizes means in general higher CPU usage. When running with a larger buffer size (which may be desirable when CPU performance is more important than latency), if the blocksize is hardcoded, the CPU penalty remains.

A runtime value would be a beneficial change for us.


Christof Ressi wrote on 16/01/2022 18:04:
> This sounds reasonable. I have made a feature request on GitHub: https://github.com/pure-data/pure-data/issues/1549
> 
> When I have time, I can make a PR. Or maybe someone else wants to do it?
> 
> Christof
> 
> On 16.01.2022 17:15, Athos Bacchiocchi wrote:
>> 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
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list