[PD] logical timing question
plessas at mur.at
Sun Jan 11 13:42:19 CET 2009
(see for comments below)
Roman Haefeli wrote:
> On Sun, 2009-01-11 at 12:26 +0100, Peter Plessas wrote:
>> Timing is a very interesting topic in pd (and with computers in
>> general). When i try to measure the [realtime] of a [metro 4] object, i get:
>> print: 11.351
>> print: 0.122
>> print: 0.11
>> print: 11.402
>> print: 0.088
>> print: 0.119
>> print: 11.374
>> I think you get the same values. Can it be true that there is a
>> deviation of 7ms now and then? More interesting: Why is it not only
>> now-and-then, but every fourth sample? So there must be some phase shift
>> which accumulates in the operation of [realtime].
>> On averaging those values, one gets a value close to 4ms though.
>> Does anyone know about the real-life resolution of [realtime]?
> those time steps seem to be related to the audio driver. you seem to run
> pd on jack with a latency of 23ms / 512 frames per buffer @ 44.1kHz.
> when i use 2048 per buffer at 44.1kHz, i get 92 ms latency and the
> numbers look like this:
I did this test with -audiobuf 50 running OSS.
You are right, the values differ greatly on the kind of audio driver i
am using, f.e. with alsa and -audiobuf 50 i get:
while using alsa and -audiobuf 100 the result is slightly different as
well. And all this while DSP processing is even turned off.
> i guess, if you want really accurate realtime values, you would have to
> go for the least possible latency, since it seems, that time of
> execution of pd is completely dependent on the audio driver. and even if
> this would cause drop-outs, the results of [realtime] wouldn't be
> affected in a way, that the overall measured time is still valid. if you
> use [timer], which measures logical time, and you get drop-outs, all
> dropped out time is not part of the measurement and you will get wrong
> (too small) values as a result.
So realtime is dependent on the audio clock? I always thought that it
took the cputime/OS time...
I understand that logical time in timer is the internal "perfect"
representation of pd's time.
> i never understood, why [timer] is giving different values from the ones
> that you expected, when connected to a [bang~] inside a re-blocked
> subpatch. would be cool to have that either explained or declared as a
Yes, that one is still unclear to me.
More information about the Pd-list