[PD] Latency compensation

Simon Iten itensimon at gmail.com
Wed Oct 19 13:42:25 CEST 2016

> On 19 Oct 2016, at 10:20, Roman Haefeli <reduzent at gmail.com> wrote:
> [replying to pd-list]
> Hi Simon
> On Wed, 2016-10-12 at 09:30 +0200, Simon Iten wrote:
>> it would very much surprise me, if pd could do that in a generic way
>> on all platforms. even daws or live struggle to do this *right* on
>> different systems. 
> I'm not sure it's totally impossible. With jack, the latency is
> dependent on jackd's settings and I don't whether Pd has a change to
> know those. With ALSA, everything you need to know to calculate the
> latency Pd already knows.
but there is also an ADC and DAC latency, is jack or alsa aware of those as well? i believe typical adc/dac conversion can take up to 1.5ms…

>> why don't  you patch a little tester app that sends some generated
>> sounds, preferably with very clear attack, out and record this back
>> in. that way you can measure the (roundtrip) latency of the whole
>> system.
> Of course, that is a way. "Knowing" the latency instead of "measuring"
> it would be so nice, though.
of course knowing is better than measuring :)

i think it is easy enough to measure roundtrip latency, it is harder to measure just “output” latency.

>> with a click track and a good musician that plays with it (that you
>> record) you should be able to align generated sounds and live
>> recorded material. this is how we do it in the studio if necessary :)
>> but it is far from an automated process...
> To make things at least a bit more feasible, I make the measured or
> calculated latency a configuration parameter, so that when you fire Pd
> up the next time with the same setup, the patch remembers the latency.
that sounds reasonable.
> Roman
>> Am Sonntag, 9. Oktober 2016 schrieb Roman Haefeli :
>>> Hi all, 
>>> I'm currently investigating audio latency compensation in Pd. The
>>> goal
>>> is for recorded audio to align well with generated sounds timing-
>>> wise.
>>> I'm wondering now what methods people already have employed in
>>> order to
>>> achieve that goal.
>>> So far, I was able to find the formulas to calculate the correct
>>> latency when using ALSA and JACK audio back-ends as long as the
>>> paramaters 'Delay(msec)' and 'Block size' for ALSA, respectively
>>> 'Frames/period' and 'Periods/buffer' for JACK are known. Currently,
>>> this approach works, but requires me to tell the latency
>>> compensation
>>> calculator what driver I'm using and what the current settings are.
>>> Also, it yet only works on Linux, but not with any other drivers
>>> like
>>> CoreAudio, ASIO, etc.
>>> How can I achieve correct latency compensation reliably on any
>>> platform? Is there some more generic way?
>>> I'm also looking at IEM's mediasettings library, hoping it would
>>> deliver the required information to calculate latency. The
>>> README.txt
>>> says 'get/set Audio and MIDI settings within Pd', but I wasn't able
>>> to
>>> find a way to _get_ current settings other than 'advance 100',
>>> which
>>> probably refers to 'Delay(msec)' set to '100'. But still, if it
>>> would
>>> give all Pd audio settings, how would it know about current jackd
>>> settings?
>>> Roman
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161019/7f6551b9/attachment-0001.html>

More information about the Pd-list mailing list