[PD] JACK affects UDP rate

[Miller Puckette]

Yes.  Also, I beleive jacks' setup assumes that all its clients share
the same latency (set via jack's buffer size and number of buffers) so
if you want to mix high-and-lower latency operations you might need to
add some to a Pd instance.

'Git blame' is blaming almost the entire s_audio_jack file on me, although
I'm sure someone else initially wrote it, probably Iohannes.  But the
current state of the callback scheme is certainly all my fault.

I think it's best to tweak audio stuff as early as possible in the Pd
dev cycle since it tends to need more shaking out than other components, so
I'll put that at the head of the list for now.

cheers
M

On Sat, Jul 24, 2021 at 04:19:43PM +0200, Christof Ressi wrote:
> > The only advantages I see are:
> 
> Yesterday was a bit too late, so I forgot the most important advantage of
> the "Delay" parameter: reduced overall latency!
> 
> Generally, in the polling scheduler, the total input latency is the hardware
> buffer size + the "internal" buffer size. In contrast to the callback
> scheduler, a larger hardware buffer size itself doesn't buy you anything -
> it is really the internal buffer that gives you the extra leeway.
> 
> The polling scheduler in the Jack back end uses a simple double buffering
> scheme where the size of the buffer has to be the same as the hardware
> buffer size. As a consequence, you always end up with unnecessary extra
> latency.
> 
> On the other hand, the Portaudio back end uses a true ring buffer whose size
> is independent from the hardware buffer size. Usually, you would set the
> hardware buffer size to the lowest possible stable value (ideally 64
> samples) and only control the latency via the size of the ring buffer (=
> "Delay").
> 
> ---
> 
> If my analysis is correct (if not, please let me know!), I think the Jack
> backend should really adapt the lock-free FIFO from the Portaudio backend.
> 
> Christof
> 
> On 24.07.2021 04:16, Christof Ressi wrote:
> > Hmmm... in the jack backend there is no ring buffer. Jack just dumps a
> > large buffer from the audio callback and notifies the Pd audio thread,
> > which consumes the buffer in chunks of 64 samples.
> > 
> > I think you could just copy the port audio backend implementation with
> > its lock-free ringbuffer. This would also solve the socket polling issue
> > :-)
> > 
> > Maybe the "polling scheduler" part could even be moved out of
> > "s_audio_pa.c" and shared with the jack backend.
> > 
> > ---
> > 
> > On the other hand, I've been wondering if the "Delay" parameter is
> > actually necessary at all. As the Jack backend demonstrates, you can
> > just as well use a larger hardware buffer size. The only advantages I
> > see are:
> > 
> > * latency can be controlled at a finer granularity; hardware buffer
> > sizes are usually power-of-2s, so there's no step between 11.6 ms (512
> > samples) and 23.3 ms (1024 samples), for example.
> > 
> > * the latency can be set arbitrarily high while the hardware buffer size
> > is limited (often 1024 samples)
> > 
> > Unfortunately, very few people actually seem to understand the
> > difference between the "block size" (= hardware buffer size) and the
> > "Delay" in Pd's audio settings and how they interact... But maybe that's
> > just because of the lack of documentation. After all, I only understood
> > it after reading the code :-)
> > 
> > Christof
> > 
> > On 24.07.2021 03:05, Miller Puckette wrote:
> > > Aha.. I've been meaning to look at why jack doesn't respond to audio
> > > latency
> > > setting... I think it needs fooling with.
> > > 
> > > cheers
> > > M
> > > 
> > > On Sat, Jul 24, 2021 at 01:01:43AM +0200, Christof Ressi wrote:
> > > > Hi Miller,
> > > > 
> > > > > As I understand it, when Pd is idle (finishes a 64-sample
> > > > > block and can't yet
> > > > > crunch the following one), then it goes back and re-checks
> > > > > for network or
> > > > > GUI input, and keeps doing that until either there isn't
> > > > > anything to read or
> > > > > else the next block becomes runnable.
> > > > AFAICT, that's true for pa_send_dacs(), but not for
> > > > jack_send_dacs(). The
> > > > former calls sys_microsleep() in a loop, so it will only
> > > > actually sleep if
> > > > there are no more sockets to read; the latter immediately blocks on a
> > > > condition variable if the buffer is not available.
> > > > 
> > > > > I need to add some sort of poll-it-again functionality to
> > > > > libpd but haven't
> > > > > figured out what shape it should take yet.
> > > > Since libpd manages the audio callback, the client can simply call
> > > > sys_pollgui() as often as they want/need. I don't think that you
> > > > actually
> > > > have to add anything. Maybe just add a more fitting alias, like
> > > > sys_poll()
> > > > or sys_pollsockets()? sys_pollgui() is really a misnomer...
> > > > 
> > > > Christof
> > > > 
> > > > > So this is a simple throttling
> > > > > mechanism.  (And it's not necessary to put this on another thread).
> > > > > 
> > > > > However, in the context of libpd thre's no concept of "idle"
> > > > > and so in that
> > > > > setup there's only one network read per block.
> > > > > 
> > > > > And yes, this can lead to delays since the Macintosh
> > > > > helpfully stores unread
> > > > > packets until the reading process gets around to realding
> > > > > them.  I think that
> > > > > also only happens in the context of libpd.
> > > > > 
> > > > > I need to add some sort of poll-it-again functionality to
> > > > > libpd but haven't
> > > > > figured out what shape it should take yet.
> > > > > 
> > > > > Miller
> > 
> > 
> > 
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwIDaQ&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=E8VWVvpZbu33knKsSGU37_SSsIBrelccBcViM5NLL-o&s=acgmJDMFU8UIb9Bi-GJn1QMgu9nZcOraYi74_05D_QI&e=

--