[PD] logical timing question

[Peter Plessas]

Thanks Roman,

(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:
print: 0.1
print: 4.928
print: 4.991
print: 4.951
print: 4.994
print: 0.098
print: 4.931
print: 4.994
print: 4.949

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

Yes, that one is still unclear to me.

regards, Peter