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.