On Feb 4, 2023, at 11:46 AM, Denis Połeć <denis.polec@gmail.com> wrote:As far as I can tell, everything is going smoothly with the callback settings.However, I still haven't quite understood what it is for.
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