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. 

Attachment: signature.asc
Description: This is a digitally signed message part

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

Reply via email to