[PD] JACK affects UDP rate

[Miller Puckette]

On Fri, Jul 23, 2021 at 11:59:26PM +0200, Christof Ressi wrote:
> On 23.07.2021 23:11, Roman Haefeli wrote:
> 
> > On Fri, 2021-07-23 at 21:52 +0200, Christof Ressi wrote:
> > > When we overhauled the networking code, I noticed that the TCP and
> > > UDP functions would both read up to N bytes (where N is currently
> > > 4096) in a single recv() call. With TCP the buffer can contain
> > > several FUDI (or other) messages, but with UDP it would only contain
> > > a single packet. So UDP was effectively much more rate limited than
> > > TCP.
> > I think, it _does_ make sense to treat TCP and UDP differently. With
> > TCP, you probably want to consume only as much as you can eat at the
> > time while keeping the rest buffered for later. OTOH, it's questionable
> > whether "surplus" UDP packets should be stored for later. Rather - I
> > think - they should be simply discarded.
> 

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.  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