<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> Are there situations when using
callbacks (on CoreAudio) bring any benefit?</pre>
</blockquote>
</p>
<p>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).<br>
</p>
<p>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 <i>hardware buffer
size</i> 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.</p>
<p>(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...)<br>
</p>
<p>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.</p>
<p>Christof<br>
</p>
<div class="moz-cite-prefix">On 04.02.2023 10:59, Roman Haefeli
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d4b614a0df379efb00f12b64c4132a1a6b855211.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">On Sat, 2023-02-04 at 10:04 +0100, Dan Wilcox wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Do you have callbacks enabled? If so, disable the checkbox in the
audio dialog.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</body>
</html>