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
On 23.07.2021 14:39, Roman Haefeli wrote:
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