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