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?

Roman

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list