[PD] JACK on macOS

Christof Ressi info at christofressi.com
Tue Dec 14 16:04:08 CET 2021


Forgot to say: the callback scheduler will not be removed. If it works 
for you, by all means keep using it!

On 14.12.2021 15:53, Christof Ressi wrote:
>> 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
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list





More information about the Pd-list mailing list