Actually, I just remember that I fixed a very similar issue with the ASIO backend. However, it was a bit more nasty, because Pd would simply crash if the "Delay" value was too low :-) My solution was too simply cap the value at the hardware blocksize:
---
The problem with the Jack backend is that it caps at *Pd's* blocksize (64 samples) - which is often lower than the Jack buffersize. Consequently, the Jack callback might never have a chance to fill the ring buffer.
I think the solution is simple:
In jack_open_audio() replace
if (advance_samples < DEFDACBLKSIZE)
advance_samples = DEFDACBLKSIZE;
with
if (advance_samples < jack_blocksize)
advance_samples = jack_blocksize;
@Roman: can you give this a try?
Christof
On Tue, 2022-03-22 at 15:23 +0100, IOhannes m zmoelnig wrote:On 3/22/22 15:06, Roman Haefeli wrote:On Tue, 2022-03-22 at 14:56 +0100, Christof Ressi wrote:Anyway, I can open an issue to describe that in my case DSP only works with callbacks on.Yes, please! The Jack backend is supposed to work regardless of the "callback" setting.But not regardless of the "delay (ms)" setting. If it is too low, Pd won't process audio. I don't know if there is a way to know beforehand what 'too low' is. It isn't necessarily a bug in Pd, I'd say.it's probably a bug in Pd if the DSP and the GUI both freeze.Indeed, if the buffer is set too small, then Pd GUI freezes! >From my anecdotal testing, it looks like the critical value is predictable. As Christof said, the buffer cannot be smaller than JACK's blocksize. For instance with JACK @ 256 samples @ 44.1kHz (5.8ms): - Pd works with 6ms - Pd freezes with 5ms I guess the dialog could be designed in a way to set a lower boundary that is dependent on the detected JACK blocksize. I don't know, however, if Pd is able to detect the blocksize before DSP is turned on. Roman
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list