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