[PD] JACK affects UDP rate

[Miller Puckette]

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

--