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