[PD] JACK affects UDP rate

[Christof Ressi]

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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210723/f974c0a9/attachment.htm>