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:
2. 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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
