[PD] JACK on macOS

[Christof Ressi]

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