[PD] JACK affects UDP rate

[Christof Ressi]

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