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@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@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= > -- _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list