[PD] logical timing question

[Roman Haefeli]

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:

print: 0.048
print: 0.047
print: 0.033
print: 0.049
print: 0.05
print: 45.916
print: 0.04
print: 0.05
print: 0.051
print: 0.052
print: 0.035
print: 0.05
print: 0.064
print: 0.052
print: 0.032
print: 0.046
print: 0.048
print: 45.825
print: 0.033
print: 0.047

so, here every 12th number is significantly bigger than 0 and also here,
this number is approximately the half of the latency. this behaviour
seems to be typical for jack. when i run pd in windows in virtualbox, i
get more random looking numbers.

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. 

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
bug.

roman




		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de