Aha.. I've been meaning to look at why jack doesn't respond to audio latency setting... I think it needs fooling with.
cheers M
On Sat, Jul 24, 2021 at 01:01:43AM +0200, Christof Ressi wrote:
Hi Miller,
As I understand it, when Pd is idle (finishes a 64-sample block and can't yet crunch the following one), then it goes back and re-checks for network or GUI input, and keeps doing that until either there isn't anything to read or else the next block becomes runnable.
AFAICT, that's true for pa_send_dacs(), but not for jack_send_dacs(). The former calls sys_microsleep() in a loop, so it will only actually sleep if there are no more sockets to read; the latter immediately blocks on a condition variable if the buffer is not available.
I need to add some sort of poll-it-again functionality to libpd but haven't figured out what shape it should take yet.
Since libpd manages the audio callback, the client can simply call sys_pollgui() as often as they want/need. I don't think that you actually have to add anything. Maybe just add a more fitting alias, like sys_poll() or sys_pollsockets()? sys_pollgui() is really a misnomer...
Christof
So this is a simple throttling mechanism. (And it's not necessary to put this on another thread).
However, in the context of libpd thre's no concept of "idle" and so in that setup there's only one network read per block.
And yes, this can lead to delays since the Macintosh helpfully stores unread packets until the reading process gets around to realding them. I think that also only happens in the context of libpd.
I need to add some sort of poll-it-again functionality to libpd but haven't figured out what shape it should take yet.
Miller