[PD] DSP crashing - PD freezes.

[Christof Ressi]

>   Are there situations when using
> callbacks  (on CoreAudio) bring any benefit?

With "callbacks" enabled, Pd runs directly on the audio thread. 
Generally, this is not really recommended because Pd itself is not 
realtime safe. Many operations block for an indeterminate amount of 
time, e.g. any call to "malloc()", network IO, file system operations, 
etc. The upside is that you can avoid some extra delay (see below).

With Pd's ringbuffer scheduler (= "callbacks" disabled), you can freely 
adjust the delay according to  your needs. (The "delay" parameter 
basically sets the size of the ringbuffer.) The price you pay is some 
extra delay (1x the hardware buffer size). To minimize this extra delay, 
you would set the /hardware buffer size/ as low as possible (e.g. 64 
samples) since the audio callback does nothing but transfer a bunch of 
samples. In this case, the extra latency would be as low as 64 samples, 
so nothing to worry about too much.

(The "callback" option can indeed make a noticable difference when using 
Jack with larger block sizes. Ideally you would just use the smallest 
Jack block size possible, but this might not work well for other Jack 
clients...)

As a side note: up until now, Pd's scheduler thread regularly goes to 
sleep for a fixed duration, so it may wake up a bit too late. If the 
delay setting is too low, this can lead to drop outs. With my 
"scheduler_fix" branch, the scheduler thread waits on a semaphore and is 
notified immediately when audio data is available. In my experience so 
far, this allows for lower "delay" settings than before.

Christof

On 04.02.2023 10:59, Roman Haefeli wrote:
> On Sat, 2023-02-04 at 10:04 +0100, Dan Wilcox wrote:
>> Do you have callbacks enabled? If so, disable the checkbox in the
>> audio dialog.
> So what's the deal with Callbacks on CoreAudio/macOS? On all the
> combinations of Pd version and macOS version I tried, funny things
> happen with callbacks enabled. Are there situations when using
> callbacks  (on CoreAudio) bring any benefit? If so, what are those
> situations? I think I understand how callbacks affect the interaction
> between Pd and JACK when using JACK, but it's a bit opaque to me what
> their purpose is when using CoreAudio. On Jack, using callbacks makes
> Pd not add any additional latency on top of JACK's own latency. So,
> which latency critical applications, I was hoping to affect latency in
> similar way by using callbacks with CoreAudio.
>
> Once I touch the callback toggle, I see Pd's CPU usage jumping to 100%
> and there is no way to make go back. Even when I send `@callback 0`
> using the mediasettings library, things go havoc. Once in that state,
> it cannot be undone by toggling callback (or sending '@callback 1,
> @callback 0' to [audiosettings]). Only a restart of Pd helps.
>
> Is it expected that Pd uses 100% of core with callbacks enabled? Or
> should I report a bug? What's the supposed benefit of that toggle?
>
> Roman
>
>   
>
> _______________________________________________
> Pd-list at lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20230204/122e3b56/attachment.htm>