<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>I assume you're using [iemnet] or [mrpeach] objects? Those only
read a single UDP packet in the poll function.</p>
<p>[netreceive], on the other hand, reads several packets up to a
certain throttle limit.</p>
<p>---</p>
<p>Now to the actual problem:<br>
</p>
<p>The poll functions are called in sys_domicrosleep().
sys_domicrosleep() is usually only called *once* per scheduler
tick.</p>
<p>Actually, I have already noticed this problem with the portaudio
backend a while ago. Miller has added a fix by replacing usleep()
with sys_microsleep() in pa_send_dacs(). This means that when the
scheduler has to wait for the ringbuffer, it will continue polling
sockets and only go to sleep if there's nothing more to do.</p>
<p>jack_send_dacs(), on the other hand, immediately waits for a
condition variable. However, a similar solution could be
implemented here:</p>
<p>In a loop, check if the Jack buffer is available; if no, first
try to call sys_domicrosleep() and only if that returns 0, call
pthread_cond_wait().<br>
</p>
<p>I guess similar solutions would have to be applied to the audio
backends as well...<br>
</p>
<p>Christof<br>
</p>
<div class="moz-cite-prefix">On 23.07.2021 14:39, Roman Haefeli
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:59915a7fb54bd9c09f8d22228ac117f2f1ecbbc2.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">Hi all,
We experience "unexpected" latency with our software tpf-client [1] on
macOS. When using JACK as audio-backend and using a blocksize [2] of
64, latency grows over time, growing whenever there are dropped
packets.
The issue appears only when all three criteria are met:
* Pd is running on macOS
* Pd is using JACK as backend
* blocksize is 64
On Linux, the patch runs fine, even with JACK as backend and using
blocksize=64. When using CoreAudio on macOS, there is also no growing
latency. Using JACK on macOS also works when using blocksize=128.
I can only guess what is going on, but it seems that with JACK Pd can
only digest a limited number of incoming UDP packets. With
blocksize=64, it would receive one packet per DSP block on average.
Maybe Pd can only consume one packet per DSP tick with JACK as backend?
I once made a test patch for measuring maximum UDP throughput that
showed some hard limit. Because I didn't get the same values on two
different runs, I decided to pursue some deeper investigation another
time and suspected a problem in my test patch. It didn't occur to me
back then that the difference was between -jack and -nosound. The
difference with the test patch is significant also on Linux, though the
problem described above appears only on macOS.
This is with:
* Pd 0.51.4
* macOS 10.15.7
* JACK 0.92.3 (but happens also with newer JACK 1.9)
The tpf-client patch is using [iemnet/udpclient] for sending and
receiving JackTrip packets. The test patch shows similar difference for
both, [netsend -u -b] and [iemnet/udpclient].
Even if it can be fixed, I'm interested in having a deeper
understanding of what is going on.
Curiously,
Roman
[1] <a class="moz-txt-link-freetext" href="https://github.com/zhdk/tpf-client">https://github.com/zhdk/tpf-client</a> (Pd-patch)
[2] blocksize here is an application internal parameter unrelated to
Pd's or JACK's blocksize. It defines how many samples per channel go
into one JackTrip packet.
</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>