Hi,

I assume you're using [iemnet] or [mrpeach] objects? Those only read a single UDP packet in the poll function.

[netreceive], on the other hand, reads several packets up to a certain throttle limit.

---

Now to the actual problem:

The poll functions are called in sys_domicrosleep(). sys_domicrosleep() is usually only called *once* per scheduler tick.

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.

jack_send_dacs(), on the other hand, immediately waits for a condition variable. However, a similar solution could be implemented here:

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().

I guess similar solutions would have to be applied to the audio backends as well...

Christof

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] https://github.com/zhdk/tpf-client (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. 

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