[PD] JACK affects UDP rate

[Christof Ressi]

On 28.07.2021 13:42, Roman Haefeli wrote:

> On Wed, 2021-07-28 at 03:51 +0200, Christof Ressi wrote:
>>> On Linux, the receive buffer seems to be ~4kB, you as you already
>>> stated.
>> Where did I state that? :-)
> From: https://lists.puredata.info/pipermail/pd-list/2021-07/129893.html
>
> "Back to TCP vs UDP: let's say you are sending 32-byte FUDI messages at
> a high rate. With the old behavior, TCP allowed to receive and dispatch
> 128 messages in a row (4096 bytes in total), but UDP only allowed a
> single message. For me, this didn't make any sense. With the new
> behavior you get the same number of messages."
>
> I thought that 4096 bytes applied to the receive buffer of both, TCP
> and UDP, but that's probably not what you meant.
Yes, I was rather referring to the buffer used for the recv() call, 
which currently has a size of 4096 bytes. This is the limit of how many 
data we can receive per socket in a single sys_pollgui() / 
sys_microsleep() call, otherwise these functions might block 
indefinitely during heavy incoming network traffic. The exact value of 
the throttle limit is somewhat arbitrary. In practice it doesn't matter 
too much if the poll functions are called repeatedly, like in the 
portaudio backend. In the Jack backend, however, the poll function is 
called only once per DSP tick, so the throttle limit becomes noticable. 
Anyway, it is completely independent from the UDP receive buffer.
> OTOH, maybe once the incoming rate is not "artificially" limited to
> one-packet-per-tick anymore, this might be a non-issue.

Yes, I think so too. Of course, it is still possible to flood Pd with 
more messages than it can handle. One thing to watch out is the 
combination of a large hardware buffer size and a small UDP receive 
buffer, because Pd might be busy computing audio for several 
milliseconds - during which only a few packets can be received. If many 
packets arrive in this time window, the UDP receive buffer can overflow, 
leading to packet loss.

Another potential source of temporary packet loss are long blocking 
operations, like reading a large file from disk, during which no packets 
can be received, either.

Maybe it could also be helpful to allow users to tune the UDP receive 
buffer size for [netsend -u] resp. [netsend -u -b]. If you had a Pd 
patch that expects very high incoming UDP traffic, you could then 
increase the buffer size accordingly.

Christof