[PD] Latency compensation

[david medine]

>>
>>> 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.
A good way to do this is to make this patch: [adc~]-[dac~]. Then, attach 
one channel of your scope to an old (cut-able) audio cable connected to 
the input and another channel to another old cable on the output. Then 
just send pulses or snap your fingers or whatever and look at the lag on 
the scope.

Whatever the latency is that results from DtoA will be nearly identical 
on the AtoD side because any pro audio device is going to have exactly 
the same filter on both ends. The sampling part of the conversion is 
nearly instantaneous. It depends on your audio backend how (when) the 
samples get pushed and pulled onto the CPU but that will be short too, 
especially if you set the latency value in Pd's to as low as it will go. 
So the RTT is the only thing you can measure, but it will probably be 
very, very close to 2x the output latency (unless you use Windows, in 
which case all bets are off!).

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161019/e8f46fcc/attachment.html>