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