[PD] JACK affects UDP rate

[Roman Haefeli]

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. It would be nice, if more than
one packet could be received per tick, of course, but then to buffer
could simply be flushed, so that only "fresh" packets are considered in
the next tick. I _think_ that's what network devices do as well: send
it now or forget it. 
 
With blocksize=64, ideally one packet per tick is received. On macOS,
it seems each tick without a packet delays the processing of the
subsequent packets by one DSP block. After a few seconds on a bad
connection (Wifi, for instance), the delay settles at 200-500ms and
there is a very clean signal afterwards (which is not surprising with
such a large buffer). On Linux, the latency stays in the range set by
the receive buffer and late packets are perceived as drop out. It looks
like not processed packets are flushed on Linux, but are not macOS.
Assuming the relevant poll functions you mentioned are the same for the
same backend (JACK) on both platforms (macOS, Linux), why is the
behavior still different?

 
> My solution was this: 

You mean, as implemented in [netreceive -u]?

> we keep receiving UDP packets in a loop as long as there are pending
> UDP packets (see socket_bytes_available) *and* we haven't read more
> than N bytes in total. 

Sounds sensible to me.

Thanks a lot, Christof, for your time and effort in explaining the
details. You already helped a lot. I'm somewhat relieved that the issue
has an explanation.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210723/f3848e98/attachment.sig>