<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<blockquote type="cite"
cite="mid:215ff8f977b079c1d1bef3f646a71cb5a37de3bf.camel@gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Those only read a single UDP packet in the poll function.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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? </pre>
</blockquote>
<p>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.</p>
<p>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.
</p>
<blockquote type="cite"
cite="mid:215ff8f977b079c1d1bef3f646a71cb5a37de3bf.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">I mean could this be
addressed in iemnet without touching Pd code?</pre>
</blockquote>
<p>It can be partially addressed in [iemnet].</p>
<p>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.</p>
<p>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. <br>
</p>
<p>---<br>
</p>
<p>So the problem can be tackled from both sides:</p>
<p>1) the Jack audio backend should be fixed to poll the sockets
while idle</p>
<p>2) [iemnet] could try to receive more than one UDP packet in the
poll function<br>
</p>
<blockquote type="cite"
cite="mid:215ff8f977b079c1d1bef3f646a71cb5a37de3bf.camel@gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I guess similar solutions would have to be applied to the audio
backends as well...
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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?</pre>
</blockquote>
Sorry, yes, I dropped the "other" :-)<br>
<blockquote type="cite"
cite="mid:215ff8f977b079c1d1bef3f646a71cb5a37de3bf.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">
Roman
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</body>
</html>