[PD] JACK affects UDP rate

Miller Puckette msp at ucsd.edu
Sun Jul 25 19:17:21 CEST 2021


Well, my first attempt to fix things added 5 msec tothe latency, hmm.


On Sat, Jul 24, 2021 at 10:05:35AM -0700, Miller Puckette via Pd-list wrote:
> 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=
> 
> -- 
> 
> 
> 
> _______________________________________________
> 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=DwIFAw&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=atltc3TfvWJKhGV0sOb8FJxtvY-ccoMidY6aVUUVUek&s=_tAQ0SC5oGWdEBqzUmNjU3KDRPHmZ2HYSIhfiACZ0pg&e= 

-- 





More information about the Pd-list mailing list