[PD] JACK affects UDP rate

[Christof Ressi]

>> Those only read a single UDP packet in the poll function.
> OK, good to know. I'm glad I was not way off with my assumption. Would
> it be technically possible for the reader thread to read as many
> packets as available during a single tick?

Generally, it's not a good idea to read as many packets as *available*, 
because it could completely stall the audio thread for an undetermined 
amount of time, causing audio dropouts.

I think the current compromise works quite well: Call the poll function 
at least once per DSP tick + while the scheduler can't advance (because 
it has to wait for the ring buffer). This makes sure that we read as 
many packets as possible without stalling the audio thread.

> I mean could this be
> addressed in iemnet without touching Pd code?

It can be partially addressed in [iemnet].

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.

My solution was this: 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.

---

So the problem can be tackled from both sides:

1) the Jack audio backend should be fixed to poll the sockets while idle

2) [iemnet] could try to receive more than one UDP packet in the poll 
function

>> I guess similar solutions would have to be applied to the audio
>> backends as well...
> This I don't understand. You mean the additional check if the poll
> function has something available needs to be implemented for _other_
> audio backends as well, as in: for each separately?
Sorry,  yes, I dropped the "other" :-)
>
> Roman
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210723/f227e380/attachment-0001.htm>