[PD] Advice on how to handle latency in linux with Pd, jack and ardour

Simon Iten itensimon at gmail.com
Thu Dec 24 20:25:12 CET 2009


i asked about this issue on the ardour forum and paul davis (the main
developer of ardour) gave this answer:

All JACK clients can report latency on their ports. Pd is not reporting
latency correctly on its JACK ports. If it did, the result of the send
via Pd would still be aligned correctly.

To correct this you need to use an "artificial latency" plugin (in the
SWH plugin set) to fake the latency that Pd is adding. There's no way to
know what the number is so you just have to play with it until ardour
does the right thing. Oh, and you need to know one other thing: Ardour
only does latency updates at each transport stop, so you need to
adjust/stop/roll/adjust/stop as necessary.


furthermore, there seems to be latency correction for other jack apps,
if they report it.

hope this helps.

is the jack implementation  in pd reporting the latency?







On Tue, 2009-12-22 at 17:23 -0300, Simon Iten wrote:
> thanks for the clarification. i'll ask about the latency correction for
> jack-clients in the ardour forum. lately there have been some jack
> plugins around (linuxdsp) so there would be a need for this there as
> well.
> 
> 
> On Tue, 2009-12-22 at 11:41 -0800, Justin Glenn Smith wrote:
> > Jack cannot automatically know that PD is reading from jack and then sending back to re-record. Because of how jack is designed, there is an inevitable and predictable delay there - determined by jack, not by pd.
> > 
> > This has been brought up, ardour already automatically compensates for ladspa plugin latency when it has the proper information, so the infrastructure is theoretically there (ideally they could add a "one jack period worth of latency correction" toggle to the UI for each track).
> > 
> > Simon Iten wrote:
> > > afaik all the latency introduced by jack is automatically corrected by
> > > ardour. so the latency you observe when rerecording in ardour comes from
> > > puredata only. there's not much you can do about this, except optimizing
> > > your patch. i'm not aware of any manual latency correction in ardour,
> > > but maybe i'm wrong, you should ask this on the ardour forum. you could
> > > start your sourceaudio with a short and loud click sound, that way it's
> > > easier to align later...
> > > 
> > > regards,
> > > 
> > > simon
> > > 
> > > On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote:
> > >> I've been lately messing around with a fairly straight forward
> > >> configuration sending audio from ardour to Pd's adc~ (through jack)
> > >> and back to ardour via MIDI (for controlling automations) or audio
> > >> (trivially re-recording Pd's dac~ output).
> > >>
> > >> In the case of MIDI latency seems no perceptible problem.
> > >>
> > >> In the case of audio, where the audio is of course 'processed' in the
> > >> Pd patch and eventually 'goes back' to ardour, there is latency. 
> > >> This of course is expected for the nature itself of jack, what I'd
> > >> like to know at this stage is not how to remove latency but the best
> > >> way(s) to handle it (possibly even through raising the latency itself,
> > >> as for the moment I'm not doing real-time), for example if there were
> > >> some way to compensate it automatically (or at least in some 'smart'
> > >> way).
> > >> At the moment the best solution is to manually re-align the slightly
> > >> delayed audio.
> > >>
> > >> Any input welcome.
> > >>
> > >> Kind regards,
> > >> Lorenzo.
> > >> _______________________________________________
> > >> Pd-list at iem.at mailing list
> > >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Pd-list at iem.at mailing list
> > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> > > 
> > 
> 
> 






More information about the Pd-list mailing list