That said, I never really understood what 'callbacks' means.
It means that the Pd scheduler runs directly in the audio callback. This is what most audio applications do. However, Pd does many things that are not realtime-safe, which can be a problem.
To me it looks like "polling scheduler" means that Pd maintains its own separate (from JACK) ringbuffer whose size is given by 'delay(ms)', while 'callbacks' means no additional ringbuffer.
With the polling scheduler, the Pd scheduler runs in a seperate thread and uses a lockfree ringbuffer to communicate with the audio callback. In this case, the latter does nothing but exchanging input/output samples. The disadvantage is some extra latency. The advantage is better control over latency (not restricted to the values allowed by the hardware driver) and more tolerance towards non-realtime-safe operations.
However, for me using 'callbacks' is not at all legacy and it would hurt our team project if it would be removed. From what I measured, the latency added by Pd with 'callbacks' unchecked is roughly the number specified in 'delay(ms)'. With 'callbacks' checked, Pd behaves like many other JACK clients and doesn't add any latency on top of the buffersize induced latency of JACK.
Ah, I see the issue. When using the polling scheduler, you would typically use the lowest possible hardware buffer size (ideally 64 samples) and use "delay" to control the latency. In theory, the polling scheduler only adds one block of 64 samples of extra latency (compared to the callback scheduler). In practice, the extra latency is at least the hardware buffer size because for every hardware buffer the Pd scheduler is ticked several times in a row, so the ring buffer must be large enough not to overflow.
If the Jack server uses a larger hardware buffer size, the extra latency of the polling scheduler becomes more pronounced.
Christof
On 14.12.2021 15:18, Roman Haefeli wrote:
On Tue, 2021-12-14 at 14:45 +0100, Christof Ressi wrote:
- turn on "callbacks" in Pd's audio settings (it seems that this
is required on macOS)
Are you sure? In my understanding, the "callback scheduler" is generally legacy and usually you would always use the "polling scheduler". (Both the Jack backend and the portaudio backend support both modes.)
Here's my experience with my on own (recent) Pd build on macOS Catalina and with JACK from jackaudio.org:
Pd works fine with JACK. It works with 'callbacks' unchecked (default) and with 'callbacks' checked. However, for me using 'callbacks' is not at all legacy and it would hurt our team project if it would be removed. From what I measured, the latency added by Pd with 'callbacks' unchecked is roughly the number specified in 'delay(ms)'. With 'callbacks' checked, Pd behaves like many other JACK clients and doesn't add any latency on top of the buffersize induced latency of JACK. So, if low latency is a concern, it seems using 'callbacks' is the the way to go. OTOH, I managed to kill ardour and jack while being connected to Pd with 'callbacks' checked while the CPU was almost maxed out. I think it makes sense to have 'callbacks' unchecked by default for higher resilience, but I find 'callbacks' a rather valuable option.
That said, I never really understood what 'callbacks' means. To me it looks like "polling scheduler" means that Pd maintains its own separate (from JACK) ringbuffer whose size is given by 'delay(ms)', while 'callbacks' means no additional ringbuffer.
@IOhannes: re your request of Pd-JACK-macOS experiences: Probably more interesting are the results with the proposed Pd builds that are candidates for distribution than with my self-compiled Pd. I'll try to test those soon.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list