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@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
